私は『Web担当者』の仕事をのべ10年ほどやってきました。出版社で言えば『編集者』のようなもので、地味な裏方で世間にはほとんど知られていませんが、実在する仕事です。

　Web担当者は商品企画、情シス、制作会社など様々な社内外の部門と連携してWebサイトを企画・運営します。分かりやすく言えば「Web予算を取る部署」でもあります。

　Web担当者は基本的に自分で作業してはいけません。仮に文章や画像を自分で作れても、品質を保つため社外ライターやデザイン会社に敢えて任せます。HTMLやCSSなどの知識が多少あっても、Web標準やデザインガイドラインなどにキチンと準拠するため基本的には自分でコードを書きません。趣味でWebサーバーやデータベースをいじっていても、システムエンジニアではないので開発から運用まで情シスやSIerに任せます。

　結果、Web担当者はWeb関連のスキルや動向を広く浅く把握はするものの、自分のスキルを証明するような資格を業務の一環として取得することは稀です。自力で資格を取っても、それで給料が上がることもありません。職場ではいちおう「パソコンに強い人」として認められてはいますが、会社を辞めた途端にスキルを証明する手段が職務経歴書以外なくなってしまいます。

　「どんな仕事も同じでは？」と思う方もいらっしゃると思いますが、違います。私は新卒で雑誌社に入社し、編集者として働いていた時期もあります。編集者なら自身が携わった書籍が実績として残りますが、Webサイトは定期的にリニューアルされて消えてしまうため実績が形として残りません。

『加齢』という第二の壁

　そうは言っても「面接で実績をアピールすれば何とかなる」とお考えかも知れません。しかし、Web業界でこれが通用するのは若いうちだけです。

　Web分野は凄い勢いで技術が変わっていきます。ここ数年でもモバイルファースト時代の常識『レスポンシブ対応』に始まり、サーバー側で動くJavaScript『node.js』とこれに続く『Vue.js』『React』『Angular』などの各種Webフレームワーク、1ページにコンテンツを詰め込む『SPA(Single Page Application)』、Webサイトをアプリ化する『PWA(Progressive Web Apps)』など気が遠くなるような新技術の嵐です。書いている私も正直よく分からない『フロントエンド』というカオスがここにあります。

　1990年代からWebに携わっていても、意識的に知識を更新していないと「HTML5？何それ？」という状況になってしまいます。Webサイトを重くする元凶ではあるけれどもWebの華だったFlashも姿を消しました。20年前のホームページも全く表示されないことは無いかも知れませんが、この20年でWeb技術はほぼ別物になったと断言出来ます。

　「ホームページ？誰でも作れるだろ？昔はみんな自分で作ってたじゃん」こんなおじさんはもうWebを語る資格がありません。Webが進化する中で、Web担当者が直接関わる技術はCMS(Contents Management System)をポチポチするだけになりがちです。個人でWebサイトを持つ人は減り、ブログを書くことすら面倒になり、自分では何もしないおじさんになり、SNSでくだを巻くだけに、なっていないでしょうか。

　この20年間の加齢により、私は「何も出来ないおじさん」になってしまっていないでしょうか。何らかの理由で会社を辞めた元Web担おじさんに、次の仕事はあるでしょうか。

「今どきのWeb技術を何も知らないおじさん」と思われないために出来ること

　加齢とモチベーションの低下で新技術の吸収を怠った元Web担おじさんは、今どきのWebサイト運営には何の役にも立ちません。昔から、社内Web担当者は専門家とは限らず「人事異動で何となくWeb担当になった」という腰掛けの人も少なくありません。全てを丸投げにすれば、何も知らないままでも任期を乗り切ってこれた人もいるでしょう(色々とまずいのですが)。

　私は仕事を辞めたことで、自分が「今どきのWeb技術を何も知らないおじさん」ではないことを40代後半にして証明しなければならなくなりました。そもそも現代のWebサービスは社内外の様々な情報システムと連携して動くのが当たり前なので、フロントエンドだけ知っていれば良いというものではありません。

　フロントエンドの怒涛の変化にすら正直ついて行けていないのですが、少なくとも「システムなんも分からん」おじさんでは無いことを証明するために思いついた窮余の策が『基本情報技術者試験』でした。

基本情報技術者試験は、皆が思っているほど『時代遅れ』ではない

　基本情報技術者試験(基本情報、FE)の起源は、2000年度に廃止された『第二種情報処理技術者試験(情報二種)に遡ります。そのため、昔をよく知るおじさんほど「そんな化石みたいな資格を今さら取ってどうするの？」というイメージを抱きがちです。「学生が取る資格」というイメージも強く、実際試験会場で見る他の受験者も20代前後が多いように感じます。

　しかし、基本情報は世間のイメージほど化石ではありません。過去問や試験対策本を読むと、特に情報セキュリティ分野ではSaaSの社内利用、クラウドへの移行、テレワークといった旬のテーマをそれなりに盛り込んでいることがわかります。

　学生が丸暗記で取った基本情報にはあまり価値が無いかも知れませんが「実務経験に裏打ちされた基本情報(や応用情報など各種上位資格)なら無駄な知識ではない」と現場でかつて働いていた経験から断言出来ます。

で、結局どうだったの？

　実際に基本情報を受けてみれば分かりますが、この資格がカバーする分野は非常に幅広いものです。正直、世間の「学生が片手間に取るもんだろ？」という評価と比べると「おじさんにはボリューム的になかなかしんどい……」というのが元Web担おじさんの本音です。

　午前試験・午後試験それぞれ60％以上正答出来れば合格なので、「何とかなりそう」という状況ではあります。合格発表がまだ先なので結果は後日追記しますが、もし基本情報が全く役に立たない資格だとお考えなら、だまされたと思って一度受けてみることをお勧めします。

　特に、機械学習やデータ分析などでPythonを覚える機会があった方は、話のネタにPythonで午後試験を受けてみてはいかがでしょうか。長いコードが出てはきますが、選択式で「コードが書けず苦しむ」といった要素はないので安心してください

とは言え、『Not enough』

　基本情報は決して化石資格ではありませんが、良くも悪くも国家資格なのでベンダー固有のスキルやナレッジは試験範囲に含まれません。また、私のような本業マーケッターな人間は技術力だけを証明すれば良いわけではありません(技術力だけならポンコツエンジニアもどきです)。

　そんなわけで、基本情報に加えて下記のような資格を取ろうかと思案中です。

• Webマーケティング関連の資格(Google アナリティクス個人認定資格、GAIQ)
• クラウドの資格(AWS 認定ソリューションアーキテクト、AWS SAA)
• データベースの資格(OSS-DB Silver Ver.2.0、PostgreSQL)
• Web制作（あまり著名な資格が無いので、取るかは未定）

最後に：この歳からエンジニアになりたいわけではありません

　ここまでお読み頂いた方には今さらですが、「エンジニア系の資格を取る」ことと「エンジニアになる」ことは全くの別物です。40代からエンジニアの仕事を始めるなど有り得ません。あくまでも「システムに明るいWeb担当者(マーケッター)」を目指しているだけです。

　どのような事業でも、Webサイトやアプリなどを用いたデジタルマーケティングは当たり前のものになっています。エンジニアにはなれないことが分かっていても、技術的な基礎知識を薄く広くでも網羅的、体系的に持っていることがビジネスマン全般に求められている(「コミュ力が全て」ではない)と信じています。

The post 40代後半のおじさんが今さら基本情報技術者試験(FE)を受けた理由 first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

　NoSQLブームで勉強会界隈では影が薄れた感があるRDBMSですが、当たり前の存在になっただけで健在です。当サイトが使っているCMS『WordPress』にはMySQLが組み込まれていますし、当サイトを置いているAWSでもPostgreSQLがRedShiftやAuroraなど基幹サービスで使われています。

　統計モデリングを知らないのにディープラーニングでイキる人が信用出来ないのと同様、RDBMSを知らないのにNoSQLを語るのもイタい人です。私も昨年はElasticsearchなどのNoSQLやApache Igniteなどの分散データベースにハマっていましたが、自分のイタさに気づいたためPostgreSQLを学び直しています。

　NoSQLや分散データベースを業務で使いこなしている方々の講演は勉強会で聞くことが出来ますが、彼らは「RDBMSを経験した上でNoSQLに進んでいる」のです。未経験者が講演を聞いていきなりNoSQLに行くのは『悪手』です。

初心者がNoSQLや分散RDBでやりたいことはPostgreSQLでも出来ている

　NoSQLが主に扱うJSONはPosgreSQLでも『JSON型』として扱えます。IMDBで話題となったインメモリ処理はPostgreSQLでも駆使されています。分散データベースの特徴であるクエリの並列処理はPostgreSQLでもパラレルクエリとして実装されている上、特別の設定無しで自動的に使ってくれます。

　昨年、実際にApage IgniteでPCサーバ5台のクラスタを構築しましたが、数10GB程度のデータではクエリに要する時間がシングルノードのPostgreSQLの方が速かったです。2.5GbEでもLANの遅延で並列処理のメリットが相殺されてしまいます。この規模のデータでクエリを高速化するなら、32コア64スレッドのパソコンでも買えば良いと思います。

　こういう事実は、基本的すぎて勉強会ではなかなか教えてもらえないですね。エンジニアの方にとっては常識なのでしょうが……

PythonでPostgreSQLを扱うパッケージ『psycopg2』

　PythonでPostgreSQLを扱う際は『psycopg2』というパッケージを使うのが一般的なようです。視覚化のためのパッケージ『Plotly』と併せてインストールします。

(base) masaru@ASUS-TUF-Gaming:~$ conda install psycopg2
(base) masaru@ASUS-TUF-Gaming:~$ conda install plotly

Jupyter Notebookでの実装

　必要なパッケージの読み込みなどの初期設定を行います。

# -*- coding: utf-8 -*-
import psycopg2
import pandas as pd
import plotly as py
import plotly.graph_objs as go
from plotly.offline import iplot, init_notebook_mode
init_notebook_mode()

　psychopg2でデータベース接続を定義します。

def connect():
    con = psycopg2.connect("host=" + "localhost" +
                           " port=" + "5432" +
                           " dbname=" + "google_mobility" +
                           " user=" + "masaru" +
                           " password=" + "xxxxxxxxxxxx")
    return con

　続いて、クエリを定義します。

def select_execute(con, sql):
    with con.cursor() as cur:
        cur.execute(sql)
        rows = cur.fetchall()

    return rows

　定義したクエリを実行します。

con = connect()
sql =  "select * from google_mobility where SUB_REGION_1 = 'Tokyo'"
result = select_execute(con, sql)

　クエリの結果をPandasデータフレームに代入します。

df = pd.DataFrame(result)
df.head()

　とりあえず全部カラム名をつけてあげます。

columns = ["id","country_region_code","country_region","sub_region_1","sub_region_2","metro_area","iso_3166_2_code","census_fips_code","date","retail","grocery","parks","transit","workplaces","residental","place_id"]
df.columns = columns
df.head()

　Plotlyで表示するデータを設定します。

trace1 = go.Scatter(
        x = list(df.date),
        y = list(df.retail),
        mode = 'lines+markers',
        name = 'retail',
        marker = dict(
                color = 'blue'
                )
        )

trace2 = go.Scatter(
        x = list(df.date),
        y = list(df.grocery),
        mode = 'lines+markers',
        name = 'grocery',
        marker = dict(
                color = 'orange'
                )
        )

data = [trace1, trace2]

　続いて、Plotlyの特長であるスライダーを設定します。

layout = dict(
    title='Time series with range slider and selectors',
    xaxis=dict(
        rangeselector=dict(
            buttons=list([
                dict(count=1,
                     label='1m',
                     step='month',
                     stepmode='backward'),
                dict(count=6,
                     label='6m',
                     step='month',
                     stepmode='backward'),
                dict(count=1,
                    label='YTD',
                    step='year',
                    stepmode='todate'),
                dict(count=1,
                    label='1y',
                    step='year',
                    stepmode='backward'),
                dict(step='all')
            ])
        ),
        rangeslider=dict(
            visible = True
        ),
        type='date'
    )
)

　グラフを描画します。

fig = dict(data=data, layout=layout)
iplot(fig)

　スライダーを動かせるグラフの出来上がりです。

The post Jupyter NotebookからPythonでPostgreSQL 13を操作する first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

　オープンで手に入るデータはCSV形式が多く、データ型などのメタデータが失われがちです。ExcelはSQLほど厳密ではありませんがメタデータを記録でき複数のワークシートを持てるので、そのあたりに魅力を感じる方なら試してみる価値はありそうです。

　世間でExcel+Pythonが流行っているのはRPAなどの文脈もあるのだとは思いますが、メンテナンス性を考慮するとPython人材が潤沢な組織以外での導入はお勧め出来ません。職場でPythonを使える方はその時点で恵まれた職場だとは思いますが、当面は昔のPerl/AWKのような「書き捨て」用途と割り切った方が良さそうです。

The post PythonでExcelデータ処理 first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.

　ASUSのノートPCを年明けにAmazonのセールで買いました。Ryzen 4600HとGTX 1650が載ったゲーミング仕様ですが、Linuxを入れる予定です。

　Linuxを入れるのはデータベースとデータ分析、Python機械学習が目的です。PostgreSQLは6コアを使ってくれますし、Tensorflow/Kerasなどディープラーニングのフレームワークもnvidia-smiなどの設定がうまく行けばGPUの並列処理を使ってくれるはずです。

　しかし今はまだWindows 10のまま。常用しているUbuntu 20.04のLinuxカーネルがAMD Ryzen 4000系のAPUに未対応だからです。

　カーネルだけ更新して世間のTipsが使えなくなるのも嫌なので、2021年4月リリース予定のUbuntu 21.04に合わせてOSを入れ替える予定です。

　写真はDaily BuildをUSBメモリから起動したところ。AMDへの対応が遅れがちなLinuxですが、Linusも今ではAMDのThreadripperを愛用しているとのこと。このノートでUbuntuが安定稼働することに期待しています。

　このブログでは、Ubuntu 21.04のインストールから各種環境構築まで一連の過程を記事として掲載しようと思っています。

The post Ubuntu 21.04が待ち遠しい first appeared on MasaruのIT＆マーケティングBLOG | Info Tech & Marketing BLOG by Masaru.