プログラミングテスト3
問3
http://www.sekaimon.com/pbapi/search.do?searchCountry=us&keyword=BMW
や
http://www.sekaimon.com/pbapi/search.do?searchCountry=us&keyword=nike
でアクセスしてもわかるようにJSON形式でおのおのの情報が取得できます。
http://153.126.153.193:8887/test3/
で開いたページのサンプルのようにしてください。
手順は
①検索した文字列をキーワードにAPIを呼び出す
②category1テーブルに入っているカテゴリのみをリストに表示させる
③BANの値が1の場合はX、0の場合はOと表示する、1の場合はグレーにする。
サーバーアクセス手順はこちらを参考にしてください。
category1のデータの登録、更新は自由に行ってください。
デフォルトで入っているデータは削除しないでください。
なぜ紙は白いのか
「なぜ一般的なテキストエディタをはじめ、デフォルトの背景が白いのか。」
背景に色のついたテキストエディタを使ってふと考えさせられる。
今でも小中学校では黒板を使い、暗い背景色のディスプレイが根強く支持されている。
スマートフォンが普及した21世紀が17年目となってなお、チョークと黒板なのか。
真っ先に思いつくのはコスト面である。
電子化されたディスプレイは確かに便利そうではあるが、おしなべて精密機器であるからして、耐久性においてアナログに劣る。
また、消耗品としてもチョークは、タッチペンやホワイトボード用のペンよりはるかに安い。ただ安いだけではなく、書こうとして書けない、といった心配もなく、一度や二度折れたとしても使用に支障をきたさない。
そして何より、夜空に星がきらめくがごとく、暗い中での明るい色は目立ちやすく、さらにチョークは一定の太めの線で書き続けることができる。
そして何より、強すぎる光が目に負担を与えるように、背景が明るい色であった場合は、光の当たり具合によっては見えにくくなるのではないだろうか。
当たり前になり過ぎたことで、疑問を持たなくなっていることが日常には数多くある。不便さばかり目につきがちな黒板であるが、存外に今でも一定の高い実用性を保っている。
見過ごされがちな長所に気づけたように感じられたのは、ひとつの収穫であった。
なお、紙が白いのは印刷の発色をよくするためであり、人工的に漂白しているからである。
未経験でもできるエンジニア実践テスト 問1と問2
サーバーのIPアドレス 153.126.153.193
アカウント:test1 パスワードは別途報告します。
ポート:29870
Windowsの場合はWinSCP、Macの場合はFileZillaなどでサーバーに入ってください。
WinSCPの場合は下記を参考にしてください。
https://winscp.net/download/WinSCP-5.9.6-Portable.zip
でダウンロードしてZIPを解凍
青線がかかっている部分のアイコンをクリック
New Siteを選択
Hostnameに153.126.153.193
Port numberに29870
User nameにtest**
Passwordに**
全て入力してLoginをクリックしてログインする。
Yesをクリック
赤い線で囲った部分をダブルクリック
Open directoryにソースコードのパス、/var/www/test_**を入力
あとはダブルクリックで、上に階層に行けたり、下位の階層に行けるので任意のファイルを編集することができます。
問1
http://153.126.153.193:8887/test1
で見えるとおり
IDと価格のデータしか見れないの
でそれを下記の画像のように商品名も表示する
/var/www/test_8888/app/views/responsive/test1.php のファイルをいじってお願いします。
秀丸、ATOMなどのテキストエディタを使用すればわかりやすくできると思います。
DBのアクセスは
からはいって
'database' => 'sample1',
'username' => 'sample',
'password' => パスワードは別途報告します。
で入れます。
問2
http://153.126.153.193:8887/test1
と同じように
ここに商品名と価格の値を入れてDBに登録できるようにする。
/var/www/test_8888/app/controllers/Test1Controller.php
を変更して改修してください。
laravelのクエリビルダーを使ったほうがいいかと思います。
わからないことがあれば何でも質問してください。
すべて正解しなくても、そこまでの思考、どういうコードを書くのか
質問内容によって判定したいと思います。
注意としては毎時0分にソースコードは初期化されます。
Google Feed APIが完全終了したっぽいので代替えを考えてみた
前職の人から次のような内容で連絡が来た。(ちなみにその会社内にITの知識を持つ者はゼロ)
----------------------------------------------------------------------
前職でサイト内のインフォメーション(社内向けとお客様向け)を管理するため、フリーのインフォ管理アプリを使用しそのRSSをGoogle Feed APIで取得・表示していたのだが、ある時から取得(2017/1/13に確認)できなくなり今も取れていない。どうにかして。
----------------------------------------------------------------------
そこで代わりに使えるものがないか調べてみた。
まずは自分の手は動かしたくない(⇦超重要)ので作業工数を限りなくゼロにしたいのと自社内にシステムに詳しい人がいなくても運用できることを条件に探してみた。
1.phpで受ける
2.jsonで取得
3.YQL APIを使う
4.iframeを使う
1.phpで受ける
php使えないサーバーなのでダメ
社内にphpわかる人がいないと運用できない
工数ゼロじゃない
3.YQL APIを使う
これもサービスが終了した時保守できる人がいないといけないのでダメ
工数ゼロじゃない
4.iframeを使う
工数ゼロに近い
サービスが終了することもない
結局最後の4を提案した。
jsonで取ることばかりを考えていたのですっかりiframeを使うという考えが抜け落ちていた。
何事も近視眼的になるのはよくないなーと感じた出来事。
アクセスが多いテーブル、クリティカルなテーブルをチェックする時
運用年数が10年以上もあると不要なテーブルから、いっぱいあってどれが一番アクセスが多いのかをロジックから見るのは途方もない時間がかかる。
そういう時に便利なSQLがありました。
SELECT COUNT (*), object_name
FROM v$sql_plan
WHERE operation = 'TABLE ACCESS'
GROUP BY object_name
ORDER BY COUNT (*) DESC;
でアクセスが多いテーブルがわかる
これで以外なテーブルがアクセスが多い事がわかった。。
あと、パフォーマンスチューニングをしていく上でデータ削減をしていく上で消すとクリティカルなテーブルがどれかを調査する必要があります。
そこで便利なSQLがこれ、
これで各テーブルのプライマリーキーがわかるのである程度どのテーブルがどれだけ大事かがわかる。
オラクルのパフォーマンスチューニング データを削減するについて
オラクルのDBのOSのロードアベレージが高くなっているので、サポートに問い合わせてみた。
[問合せ内容や障害の詳細]
現在稼働中のWEBサービスでアクセスするテーブル(インデックス設定あり/パーティション設定なし)でデータ量が***万件近くあり、テーブル検索に対するパフォーマンスが低い状態を改善しようと考えています。
データを別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文も早くなったのでやはり効果はありかと。
新規ページ組みはじめ
2月に入り、今後実装となるホームページのコードを組み始めることとなりました。
会社の看板ともいえるホームページの作成にも、一文一文が意味を持つコードによりシステムが構築されていることを改めて実感します。
ページを改めて作るとはいえ、元のページから流用できるのものは活用しつつ、1文ずつ新しいものに更新していく作業。
今では使われなくなった古いコードを目にし、このコードが組まれた当時の背景や作成者を思うに、さながらシステムを理解することは一つの作品を理解することでもあると感じます。
業務に追われることの多い日々ですが、処理スピードを保ちつつも、多面的な視点を持ち続けられるだけのバッファを維持したまま、これから作業に当たっていきたいものです。