読者です 読者をやめる 読者になる 読者になる

セカイモンの裏側

★毎週木曜日更新★ 海外ショッピングサイト『セカイモン』のブログです。私たちスタッフの仕事風景や日々の出来事など、     “セカイモンの舞台裏”とも言える日常を綴っていきます。

プログラミングテスト2

FTP接続情報
Host(IP): 153.126.153.193
User: test1
Password: テスト時に通知します。
Port: 29870

File Transfer Protocol: SFTP 

 

WinSCPを使った接続設定例 

f:id:sekaimon-staff:20170308135116j:plain

 

■DB情報

phpMyAdmin からはいって

'database' => 'sample1',
'username' => 'sample',
'password' => 'pass',

 

■ヒント

Laravel Framework version 4.2.17を使用しています。

Laravelのリファレンスはweb上にたくさんありますので調べながら行っていただいて構いません。

 

------------------------------------------------------------------------------------------------

問1

http://153.126.153.193:8888/test2

上記URLにアクセス

 

現在商品IDしか画面に出力されていないので

商品名(item)と価格(price)を画面に出力せよ。

 

・編集対象ファイル

/var/www/test_8888/app/controllers/Test2Controller.php

 

 

------------------------------------------------------------------------------------------------ 

問2

商品名(item)価格(price)の値を入れてDBに登録できるようにする。

 

・登録先DB

DB: sample1

テーブル:test1

 

・編集対象ファイル

/var/www/test_8888/app/controllers/Test2formController.php

 

 

 

なぜ紙は白いのか

システム

「なぜ一般的なテキストエディタをはじめ、デフォルトの背景が白いのか。」

背景に色のついたテキストエディタを使ってふと考えさせられる。

今でも小中学校では黒板を使い、暗い背景色のディスプレイが根強く支持されている。

スマートフォンが普及した21世紀が17年目となってなお、チョークと黒板なのか。

 

真っ先に思いつくのはコスト面である。

電子化されたディスプレイは確かに便利そうではあるが、おしなべて精密機器であるからして、耐久性においてアナログに劣る。

また、消耗品としてもチョークは、タッチペンやホワイトボード用のペンよりはるかに安い。ただ安いだけではなく、書こうとして書けない、といった心配もなく、一度や二度折れたとしても使用に支障をきたさない。

そして何より、夜空に星がきらめくがごとく、暗い中での明るい色は目立ちやすく、さらにチョークは一定の太めの線で書き続けることができる。

そして何より、強すぎる光が目に負担を与えるように、背景が明るい色であった場合は、光の当たり具合によっては見えにくくなるのではないだろうか。

 

当たり前になり過ぎたことで、疑問を持たなくなっていることが日常には数多くある。不便さばかり目につきがちな黒板であるが、存外に今でも一定の高い実用性を保っている。

見過ごされがちな長所に気づけたように感じられたのは、ひとつの収穫であった。

 

なお、紙が白いのは印刷の発色をよくするためであり、人工的に漂白しているからである。

未経験でもできるプログラミングテスト1

システム

サーバーのIPアドレス 153.126.153.193

アカウント:test1 パスワードは別途報告します。

ポート:29870

 

Windowsの場合はWinSCPMacの場合はFileZillaなどでサーバーに入ってください。

下記の画像を参考にしてください。

f:id:sekaimon-staff:20170308135116j:plain

 

問1

http://153.126.153.193:8888/test1

で見えるとおり

f:id:sekaimon-staff:20170208174111j:plain

IDと価格のデータしか見れないの

でそれを下記の画像のように商品名も表示する

 f:id:sekaimon-staff:20170208174433j:plain

/var/www/test_8888/app/views/html/test1.php のファイルをいじってお願いします。

秀丸ATOMなどのテキストエディタを使用すればわかりやすくできると思います。

 

 DBのアクセスは

phpMyAdmin

からはいって

'database' => 'sample1',
'username' => 'sample',
'password' => パスワードは別途報告します。

で入れます。

 

問2

f:id:sekaimon-staff:20170208174841j:plain

ここに商品名と価格の値を入れてDBに登録できるようにする。

 /var/www/test_8888/app/controllers/Test1Controller.php

を変更して改修してください。

laravelのクエリビルダーを使ったほうがいいかと思います。

データベース:クエリービルダー 5.1 Laravel

わからない事があれば質問よろしくお願いします。
解けないにしてもどこまでやったか、質問の内容をみて審査したいと思います。

 

 

Google Feed APIが完全終了したっぽいので代替えを考えてみた

前職の人から次のような内容で連絡が来た。(ちなみにその会社内にITの知識を持つ者はゼロ)

----------------------------------------------------------------------

前職でサイト内のインフォメーション(社内向けとお客様向け)を管理するため、フリーのインフォ管理アプリを使用しそのRSSGoogle Feed APIで取得・表示していたのだが、ある時から取得(2017/1/13に確認)できなくなり今も取れていない。どうにかして。

----------------------------------------------------------------------

 


そこで代わりに使えるものがないか調べてみた。
まずは自分の手は動かしたくない(⇦超重要)ので作業工数を限りなくゼロにしたいのと自社内にシステムに詳しい人がいなくても運用できることを条件に探してみた。

1.phpで受ける
2.jsonで取得
3.YQL APIを使う
4.iframeを使う


1.phpで受ける
php使えないサーバーなのでダメ
社内にphpわかる人がいないと運用できない
工数ゼロじゃない


2.jsonで取得
ドメインなのでダメ
工数ゼロじゃない

 

3.YQL APIを使う
これもサービスが終了した時保守できる人がいないといけないのでダメ
工数ゼロじゃない

 

4.iframeを使う
工数ゼロに近い
サービスが終了することもない

 

結局最後の4を提案した。
jsonで取ることばかりを考えていたのですっかりiframeを使うという考えが抜け落ちていた。
何事も近視眼的になるのはよくないなーと感じた出来事。

どこまで引き返せるか

システム

20年以上前から登山を楽しんでおりますが、楽しみの中にも注意すべきことの一つに、道迷いがあります。

今でこそGPSで自分の位置が分かりやすくなりましたが、それでもなお遭難の呼び水として注意すべきところ。

山に入る前には、現在地と行き先を知るために、地図とコンパスでの確認方法を押さえておきました。

 

さて、先週に引き続き、新しいホームページの作成業務にあたっております。

一度に完成まで進むことはほぼなく、コードを1文1文編集してはプレビューを行ない、エラーの出ない組み立ての模索が続きます。

エラーが検出された際には、何を変えたことでエラーとなったかが分かっていれば、引き返すことができます。

慣れればなれるほど見落としのリスクが増すもので、いかに注意していても、時としてエラー起こりえます。

その際いかに冷静かつ素早く立て直しを行なえるかは、今どの作業を行なっているかを把握できる状態に保っていることが大きく影響します。

何をどこまで着手するのか、今どこまで進んでいるのかを見失うことのないよう、作業に当たっていきたいものです。

アクセスが多いテーブル、クリティカルなテーブルをチェックする時

システム

運用年数が10年以上もあると不要なテーブルから、いっぱいあってどれが一番アクセスが多いのかをロジックから見るのは途方もない時間がかかる。

 

そういう時に便利なSQLがありました。

 

SELECT COUNT (*), object_name
FROM v$sql_plan
WHERE operation = 'TABLE ACCESS'
GROUP BY object_name
ORDER BY COUNT (*) DESC;

でアクセスが多いテーブルがわかる

これで以外なテーブルがアクセスが多い事がわかった。。

 

あと、パフォーマンスチューニングをしていく上でデータ削減をしていく上で消すとクリティカルなテーブルがどれかを調査する必要があります。

 

そこで便利なSQLがこれ、

f:id:sekaimon-staff:20170207104033p:plain

これで各テーブルのプライマリーキーがわかるのである程度どのテーブルがどれだけ大事かがわかる。

 

オラクルのパフォーマンスチューニング データを削減するについて

システム

オラクルのDBのOSのロードアベレージが高くなっているので、サポートに問い合わせてみた。

 

[問合せ内容や障害の詳細]

現在稼働中のWEBサービスでアクセスするテーブル(インデックス設定あり/パーティション設定なし)でデータ量が400万件近くあり、テーブル検索に対するパフォーマンスが低い状態を改善しようと考えています。
データを別DBに退避し、データを20%位残して残りをDELETEでデータ削除した場合、パフォーマンスの向上は見込めるのでしょうか?
ネットでいろいろ調べた結果、データを消しても断片化が改善されないとあまり効果がでないような事も書いてありました。
できればサービスを停止せずに対応したいです。
ご回答よろしくお願い致します。

[回答]
先のご質問ですが、DELETEのみでは断片化や表の肥大化は解消できないため、こちらのみで
パフォーマンスの向上は難しい状況です。
こちらの対応に関しては以下の2点を実行いただくことで断片化や表の肥大化の解消になりますので
対応可能と判断しております。

・表のMOVE
・索引のrebuild

表のMOVEについては以下のように実行することになります。

SQL> alter table <表名> move;

*表領域名を省略した場合、デフォルト表領域に移動します。
もし明示的に指定する場合は以下のようになります。

SQL> alter table <表名> move tablespace <表領域名>;

上記を実行した場合の注意点として索引が使用不可になる点、実行中insert等の処理ができない
状態となりますので、該当表にアクセスが無い時間帯に行っていただくようお願いいたします。

また、索引が使用不可になった場合の対処として先に記載した索引のrebuildが必要となります。
索引のrebuildは以下のように実施いただくことになります。

SQL> alter index <索引名> rebuild;

上記実行中もinsert等の処理ができない状態となりますので、該当表にアクセスが無い時間帯
に行っていただくようお願いいたします。


以上、ご確認の程、どうぞよろしくお願いいたします。

 

[質問2]
回答ありがとうございます。
ご提案頂いた2点の対応で検討します。

ただ、DELETEしてからの作業となるかと思いますが、
所要時間はTOTALでどのくらいかかりますか?

データ件数:400万件→80万件
INDEX数:15

数分で終わるのか、1時間くらいか、またはそれ以上か大体の目安を教えて頂きたいです。


[回答2]
上記ですが、大変恐れ入りますが、実データ量や、Oracleのメモリ等の設定、マシンのIOや
CPU等のスペックなど様々な要素に左右されるものであるため、一概にどの程度の時間が
かかるといったような机上の計算は困難であり、目安等を提示することも難しいものと
なります。

こちらを確認するのであれば同様のスペックの環境に同様の表を作成し、実行し時間を
確認頂く以外に方法は無いものとなります。

ご期待に沿う回答とならず、大変恐縮ではございますが、何卒ご了承頂きます様お願い
いたします。

ちなみに、私の手元の環境では、数万件程の表で、索引が一つしかない状況ですが、
数分で終了しております。
そのため、先の様な点もあるため、一概に申し上げることはできませんが、1時間ほどでは
完了できる可能性があると考えております。

以上、ご確認の程、どうぞよろしくお願いいたします。

 

select segment_name, bytes, ROUND(bytes / 1024 / 1024 / 1024,2) AS GB from user_segments order by bytes desc

これでどのテーブルがどれくらいサイズがあるのかを確認

700万件程度のテーブルをdeleteしても予想通りサイズは変わらずselect文でも1行しかないのに20秒ぐらいかかった。

alter move, index rebuildで予想通りselect文も早くなったのでやはり効果はありかと。