Application)やJamstack(JavaScript/APIs/Markup)など訳の分からない技術であふれています。「PHPのままでいいじゃん」と正直思っているのですが、時代の変化から目を背けるとどんどん「昔の人」になり、「仕事では使えねーやつ」と若い人から後ろ指を差されてしまいます。基本的にはJavaScriptを用いたWebサイトの高速化とアプリ化、API連携あたりがトレンドなのだろうとは理解していますが、あまりにも複雑過ぎて手を出せないまま今日まで来てしまいました。TypeScriptなる派生言語まで出てきて、おじさんはどこから始めたら良いかすら分からず頭を抱えています。インストールおじさんに取り敢えず環境を構築してみないと分かるか分からないかも分からないので、泣きながら環境構築を始めました。フロントエンド周りの環境は複雑を極めており、エラーと試行錯誤とフォルダごと削除を何時間も繰り返すような地獄の様相です。素人なので確たることは言えませんが、フレームワークが林立して「混乱している」ように感じます。npm?npx?yarn?と首をかしげているうちに環境がぶっ壊れてしまいます。きつかったのが、またもやAnacondaとの競合です。Anacondaが起因と見られるエラーでインストールが止まってしまいました。Worldまではこぎつけることが出来ました。データ分析用とWeb開発用はアカウントを分けた方が良い完璧な設定をすればデータ分析用とWeb開発用で共通のアカウントを使うことも出来るのでしょう。複数のフレームワークが混ざることに伴うトラブルシューティングの手間を考えれば、最初からWeb開発用のアカウントを別途作成した方が苦しまずに済むのではないかと思います。半日環境構築で格闘して皆さまのお役に立てそうなTipsはこれだけでした......。今のフロントエンドは『プログラマー』になる覚悟が必要HTML/CSS、PHPあたりを軽くかじってWordPressなどのCMSをポチポチしてきただけの人には、相当厳しいと思います。今のフロントエンドは、Pythonなどと同様『プログラマー』になる覚悟が必要です。WordPressですべての用が足りている人は、無理に次のトレンドに乗る必要はないと思います。私のようにWeb担当の経験くらいしか売りモノがないおじさんは、この塹壕戦から逃れることが出来ません。フロントエンドをここまで複雑にしなければならないのか、未だに腑に落ちないところがあります。時代の変化を嘆いていても仕方ないので、可能な限りキャッチアップしていきたいと思います。そんなわけで、更新が滞り気味な私の近況報告でした。Next.js、node.js、React、TypeScriptCloudfront+LightSailでコンテンツ配信サービス(CDN)を作る自前主義なら動画まで「自前主義で行こう」と独自ドメインでサイトを再開した私ですが、動画はYouTube先生に依存しています。動画はファイルが大きいので自分のサイトに置くのは正直怖いのですが、自前主義をテーマにしてみたので動画もサイトに置いてみることにしました。お財布に余裕が無い私は迷わず3.5ドルコースを選びましたが、スペックは下記のようなものです。無名サイトなので余裕ではあるのですが、動画を置くのは怖い。『CloudFront』を入れてみることにしました。CloudFrontはWebサーバーのファイルをキャッシュして配信を代行してくれるサービスです。Connectロケーション」とあり、2021年3月時点で日本国内に17か所の配信サーバーがあります。これならWebサーバーがしょぼいままでも、動画をCloudFrontに置けば、万が一アクセスが増えてもサーバーが落ちる事態は防げそうです。仕事でアカマイなどのCDNを入れたことがある方は、とても、とても心配になると思います。実際、企業向けのサービスなので多少の出費は覚悟する必要があります。日本向けの料金が1GBあたり0.114ドルです。20MBの動画が月間1万再生されると約200GBになりますので、月22.8ドルになります。「やはり、お高い......」しかしここはぐっと歯を食いしばって「1万再生もあれば22.8ドルくらいの収入は期待出来るだろう」と前向きに考えます。CloudFront、なんとか動きましたその後試行錯誤した結果、なんとかCloudFrontを動かすことが出来ました。cloudfront次回以降、どのような設定を行ったかをゆっくり書いていきたいと思います。53、コンテンツ配信2020年代に独自ドメインは必要なのか?こんにちは、まさるです。このブログはcan.ne.jpというドメインに設置しています。whoisというサービスでドメインの登録情報を確認すると、このドメインを登録したのは1998年3月26日、と分かりました。実に、23年1ヶ月前くらいです。なんと長い年月が過ぎてしまったのでしょうか......。この化石のようなドメイン、実は維持にけっこうお金がかかっています。can.ne.jpは属性型JPドメインというもので、1年分の維持費が7700円もかかります。これとは別に、ドメイン預かりというサービスが年間3960円かかります。合計で毎年11660円も払ってます。お財布に厳しいですね......。それでもドメインを維持しているのは、can.ne.jpという3文字のドメインが珍しいからです。今となっては、単なる自己満足でしかないような気もします。ドメインを取った1998年ごろは検索エンジンがまだ発達しておらず、ドメイン名を覚えてもらったりブックマークしてもらうことに価値がありました。今は検索が全盛の時代です。URLを入力してサイトを訪問してくれる人はほとんどいません。今では昔ほど独自ドメインを取る価値が無いのは間違いありません。どのような時に独自ドメインを使う価値があるのでしょうか。独自ドメインを選ぶ最大の理由は、「コンテンツを置く先のサービスに振り回されたくない」ということです。外部サービスは終了してしまうことがありますし、ツイッターやフェイスブックのようにアカウントが特に理由もなく凍結されてしまうことがあります。した時に独自ドメインという『本拠地』があれば、心配した人がGoogleで検索して自分のサイトを確認してもらえる可能性があります。ひとつの理由が、自由なソフトでコンテンツを公開出来ることです。このサイトもワードプレスというCMSで運営しているので、自分が好きなようにサイトをカスタマイズできます。サブドメインを作ることで自分のサイトであることを証明しながら複数のサイトを運営することも出来ます独自ドメインは、集客力では、どうしても大手サービスにはかないません。技術ブログであればキータなどで記事を書いた方が、たくさんの人の目にふれると思います。大手サービスのアドバンテージを理解した上で、よそに振り回されずにサイトを運営したい方は独自ドメインを検討する余地があると思います。このブログで紹介しているギットハブ・ページーズは無料で独自ドメインのサイトを作れます。ドメイン自体の取得・維持にはお金がかかりますが、興味がある人はまずギットハブで試してみるのも悪くないと思います。Pagesを作るセキュリティが心配されるWordPress前にいた会社でキャラクター商品宣伝用のスペシャルサイトを作ることになりました。独自CMSを使っておりセキュリティ上の理由で制作会社さんからのCMS接続が難しかったため、系列会社のホスティングでサブドメインを作ることにしました。運営もコンテンツ修正が出来るようにしたかった(ベタHTMLで作ると都度制作会社さんに修正料金を払う必要がある)のでWordPressの導入を検討。情シス担当者に「WordPressはセキュリティが弱いから止めてくれ」と言われ、制作会社さんにも「ベタHTMLにしてくれ(ないと面倒だし儲からない)」と言われ泣く泣くベタHTMLにしました。WordPressのセキュリティが弱いのは動的CMSだからWordPressのセキュリティが多方面から懸念されてしまうのは、PHPという動的なサイト生成基盤を使っていることと単に「有名だから狙われやすい」のが理由です。「狙われたくないから情シスが勧めるマイナーなCMSを選ぶ」のは消極的であって根本的な問題解決になっていません。WordPressで作成した動的サイトを静的サイト(HTML+CSS+JavaScript)に変換して公開すれば、サイトが動的に生成されることによるセキュリティの問題を回避出来ます。Pagesに静的サイトとしてミラーしてみましたので、やり方をメモとして残します。https://masaru-kmt.github.io/もちろん、WordPressで静的サイトを作成したからといって大元のWordPressが安全になったわけではありません。Pagesなど公開環境に静的サイトをコミットするのが適切です。GitHubでサイト名のレポジトリを作成します。Desktopをダウンロードします(Windows/Mac)。私はUbuntuにはGitを入れていますが、Webサイトでは一度にたくさんのファイルをコミットするので今回はWindowsで試してみました。Staticは2か月前に更新されており無償なので安心WordPressから静的サイトを生成するプラグインは複数ありますが、検索上位のSEOサイト()で紹介されているプラグインは数年間更新が無かったり有料化されてしまったダメダメなものばかりです。Static』を使うことにしました。Staticの設定はパブリッシュ先のドメイン名くらいで簡単です。Desktopのレポジトリにドラッグ&ドロップし、GitHubにコミットします。Foundのまま......コミットしましたがページが表示されません。「なぜ?」と焦って検索したところ、GibHubにコミットしたHTMLがWebページとして反映されるまでに時間がかかるのが理由、のようです。Pagesは向かないようです。言え、無償でサイトを公開出来る(独自ドメインもOK)のは魅力的です。(Hub)の存在くらいは知っている」という証明にはなるので検討の余地はあると思います。ちなみに、コンタクトフォームやコメントなどWordPressの動的な機能はミラー先の静的サイトでは無効になります。静的サイトにする際は「コンタクトフォームだけ他サイトのサービスを利用する」といった対策が必要となります。NotebookをWordPressに転記するのはツライ......ということでコピペする方法を探してみたところ、nbconvertを使う方法が良さそうです。gstore-cust-revenue-prediction.ipynb生成されたHTMLから該当セルをWebブラウザーのインスペクター(F12キーを押下)でコピーし、WordPressのカスタムHTMLブロックに貼り込みます。Notebookセル用のCSSを追加します(リンク先ページのソースを参照のこと)。/home/masaru/data/kaggle_google_analytics/test_v2.csv/home/masaru/data/kaggle_google_analytics/submission.csv/home/masaru/data/kaggle_google_analytics/deep-learning-keras-ga-revenue-prediction.ipynb/home/masaru/data/kaggle_google_analytics/gstore-cust-revenue-prediction.ipynb/home/masaru/data/kaggle_google_analytics/ga-customer-revenue-prediction.zip/home/masaru/data/kaggle_google_analytics/test.csv/home/masaru/data/kaggle_google_analytics/sample_submission_v2.csv/home/masaru/data/kaggle_google_analytics/GoogleAnalytics_Customer_Revenue_EDA_and_Prediction.ipynb/home/masaru/data/kaggle_google_analytics/sample_submission.csv/home/masaru/data/kaggle_google_analytics/train_v2.csv/home/masaru/data/kaggle_google_analytics/train.csv/home/masaru/data/kaggle_google_analytics/.ipynb_checkpoints/gstore-cust-revenue-prediction-checkpoint.ipynb/home/masaru/data/kaggle_google_analytics/.ipynb_checkpoints/GoogleAnalytics_Customer_Revenue_EDA_and_Prediction-checkpoint.ipynb無事、表示出来ました。CUDAドライバで大丈夫でしたまず最初にお断りですが、私はTensorflowの技術的な詳細やディープラーニングの技術については知識が全くありません。単なるインストールログですので、技術的なご期待にはお答え出来ません。GPUは動かないのではないかと思っていましたが、実際はcuda_11.2.2_460.32.03_linux.runがすんなり動きました。Notebookでの作業となります。len(tf.config.list_physical_devices('GPU'))print(gpu_num)1勉強会でみんな大好きiris、titanic、mnistを今さらやっても得られるものは無さそうなので、文系の私でも興味を持てそうなサンプルコードを見つけて実行してみようと思います。13を操作するまずは堅実に定番RDBからNoSQLブームで勉強会界隈では影が薄れた感があるRDBMSですが、当たり前の存在になっただけで健在です。当サイトが使っているCMS『WordPress』にはMySQLが組み込まれていますし、当サイトを置いているAWSでもPostgreSQLがRedShiftやAuroraなど基幹サービスで使われています。統計モデリングを知らないのにディープラーニングでイキる人が信用出来ないのと同様、RDBMSを知らないのにNoSQLを語るのもイタい人です。Igniteなどの分散データベースにハマっていましたが、自分のイタさに気づいたためPostgreSQLを学び直しています。NoSQLや分散データベースを業務で使いこなしている方々の講演は勉強会で聞くことが出来ますが、彼らは「RDBMSを経験した上でNoSQLに進んでいる」のです。未経験者が講演を聞いていきなりNoSQLに行くのは『悪手』です。初心者がNoSQLや分散RDBでやりたいことはPostgreSQLでも出来ているNoSQLが主に扱うJSONはPosgreSQLでも『JSON型』として扱えます。IMDBで話題となったインメモリ処理はPostgreSQLでも駆使されています。分散データベースの特徴であるクエリの並列処理はPostgreSQLでもパラレルクエリとして実装されている上、特別の設定無しで自動的に使ってくれます。IgniteでPCサーバ5台のクラスタを構築しましたが、数10GB程度のデータではクエリに要する時間がシングルノードのPostgreSQLの方が速かったです。2.5GbEでもLANの遅延で並列処理のメリットが相殺されてしまいます。この規模のデータでクエリを高速化するなら、32コア64スレッドのパソコンでも買えば良いと思います。いう事実は、基本的すぎて勉強会ではなかなか教えてもらえないですね。エンジニアの方にとっては常識なのでしょうが......💦PythonでPostgreSQLを扱うパッケージ『psycopg2』PythonでPostgreSQLを扱う際は『psycopg2』というパッケージを使うのが一般的なようです。視覚化のためのパッケージ『Plotly』と併せてインストールします。必要なパッケージの読み込みなどの初期設定を行います。init_notebook_modeinit_notebook_mode()psychopg2でデータベース接続を定義します。con続いて、クエリを定義します。rows定義したクエリを実行します。sql)クエリの結果をPandasデータフレームに代入します。pd.DataFrame(result)df.head()とりあえず全部カラム名をつけてあげます。columnsdf.head()Plotlyで表示するデータを設定します。trace2]続いて、Plotlyの特長であるスライダーを設定します。))グラフを描画します。layout=layout)iplot(fig)スライダーを動かせるグラフの出来上がりです。私が初めて独自ドメインでWebサイトを立てたのは20年も前になります。2010年代以前に作ったサイトで今も残っているものはひとつもありません。このcan.ne.jpドメインにもかつて別のブログがありましたが、もはやデータ復旧もままなりません。不慮の事故、モチベーション喪失、技術の変化......。さまざまな理由でサイトは「死ぬ」のです。AdobeのFlash廃止でも話題になりましたが、多くのサイトが更改しなければ表示も難しくなり、いずれWebからひっそりと消えてなくなります。WordPressというオープンソースCMSのデファクトスタンダードが確立したことで、少なくともサイトデータのサルベージは行い続けられる可能性が高まりました。個人サイトは次々と書き捨てられていく商業サイトと異なり「生きた証」でもあるので、なるべく『生涯現役』を続けたいところです。商業サイトではクラウド上にバックアップを取るのが一般的です。複数のクラウドに分散することはあっても、ローカルへの手動バックアップを前提としているサイトは少ないでしょう。個人サイトはクラウドの契約解除や無償ストレージ終了などでバックアップも消えてしまうのが常です。消える直前で対策すればサルベージや移行は可能ですが、仕事や生活の多忙で断念するケースも多いのが現実。最終的には物理的に手元にもデータを置いておくのが一番です。『Local』はPC上にLAMPやLEMPなどにWordPressを加えたスタックをウィザード形式で構築し、クラウドからバックアップしたデータでローカルサイトとして表示、管理出来るソフトです。無償版があるので個人サイト向きです。Windows、Mac、Linuxの主要OSに全て対応しているのも魅力的です。当サイトを実際にローカルでミラーしてみましたので、メモを残します。バックアップLocal自体にはクラウド上のWordPressサイトをバックアップする機能はありません。WordPressにはバックアップ用のプラグインが複数ありますが、今回は『BackWPup』を使います。バックアップ対象は『DBバックアップ』『ファイル』『プラグイン』の3つ、宛先は『フォルダー』、圧縮形式は『zip』にしました。バックアップファイルはまずクラウド(LightSail)上に作られますので、『バックアップ』サブメニューから『ダウンロード』を選んで取得します。Site』でzipファイルを読み込みます。LAMPのバージョンはクラウドと合わせるLocalはWebサーバにApacheとnginxを選べるなどスタックの選択肢が充実しています。サイトの再現性の観点から、なるべくクラウド上のスタックとバージョンを合わせた方が良いそうです。クラウド上のWordPressサイトがほぼローカルで再現Ubuntu上のLocalでWordPressサイトが表示されたご覧のとおり、ローカルドメイン(can.ne.jp.local)でWordPressサイトが表示されています。テーマやプラグインまで再現されているので、クラウド上のサイトイメージそのままで見られるのは嬉しいところです。管理画面もローカルで動く管理画面もローカルで動いています。この環境を複数のPCやMac上に持っておけば不測の事態でも生き延びた端末から復旧が出来そうです。Web分野のトレンドが大きく変わってしまったときは、Localで過去のサイトデザインを確認しながら、どのように移行させるか検討することになるでしょう。BackWPup、Local、WordPressKaggleのデータをコンペ以外の目的で利用するデータサイエンティストに敵わないからといって避けて通るのはもったいないKaggleはコンペティションで有名なため「データサイエンティスト以外はお断り」というイメージがあります。優秀な方々に及ばないことが分かっていてもKaggleを避けて通るのはもったいないと思います。BIツールの学習など、実務寄りのデータがほしい機会は多くあります。Kaggleにどのようなデータがあるか知っていれば、目的に近いデータを入手出来ます。マーケティング分野のデータは企業秘密の塊であり一般公開されることが少ないため、Kaggleのデータはとても貴重なものです。spend」をご紹介します。実在するEコマースサイトのアクセスログこのコンペはRStudio社の主催で、GoogleのEコマースサイト『GStore』のセッション単位のアクセスログが約33GB、提供されています。CSVのカラムにJSON風のデータが詰め込まれていて処理が手強いですが、BIツールの基本である日次統計にもってこいです。参考書籍などで数10GBのデータを扱っている例は見たことがありませんが、これくらいのサイズがなければExcelで十分であり、データベースやBIツール、データ分析基盤などのスケーラビリティを試すなら最低でもGB単位のデータが必要です。昨年はこのCSVデータを自力での展開を試みましたが、データ構造が複雑なため簡単な置換処理ではテーブル構造に出来ませんでした。今年は先達の方のnotebookなどを参考にして、まずはPostgreSQLへのデータ格納までたどり着きたいと考えています。他の方から学べるのもkaggleの良いところですね。21.04の基本的なインストールが終わりました。Buildでの導入でしたが、既にリリース月ということもあり大きな障害はありませんでした。2日目以降は細かい環境構築と機械学習周りの整備となります。S.M.A.R.T対応のSSDなどの状態を調べるツール。このPCの内蔵SSDは非対応な模様どれもインストールが特に難しいということはありませんでしたので、詳細説明は割愛します。当サイトではPayPay送金による寄付をお願いしております。記事が役に立ったら100円でも結構ですのでお送り頂けると嬉しいです。WordPress.。