すのふら

すのふら

日々の備忘録

フォトカツが終わった日

f:id:snofra:20180712230937j:plain

アイカツ! フォトonステージ!!』が2018年7月11日をもってサービス終了した。

2016年1月28日配信開始なので、サービス期間は2年半くらい。

いろいろなソーシャルゲームをつまんでは止めアンインストールしている俺にとって、フォトカツは最初から最後までお付き合いする初めてのソーシャルゲームだった。

だからか終了のアナウンスが俺のtwitterのタイムラインに流れてきたときに、(歌唱担当も卒業したし)なんとなく予想はしていたけどついに来たかという、そんな気持ちだった。


フォトカツに重課金とはいかないまでも多少課金をしてきていたので、課金した金返せとか思うのかなと思っていたけど、意外にそんな気持ちは沸いてこなかった。

ただただ終わってしまうのか……。そんな気持ち。

その気持ちを持ったまま今終わりを迎えて、フォトカツのアプリを開くと終わりのメッセージがあって、ああ、本当に終わってしまったんだなって。

f:id:snofra:20180712230452j:plain


事実を事実として受け入れるという気持ち。

そこに感情とかはあまり乗ってこなくて、
そういや美月さんのクレーンゲームのシナリオは的確にキャラクターを捉えていたなーとか、
初めて伝説級クリアしたのハローハローだったなー、そこからこの曲好きになったなーとか、
青い苺、アイカツメロディ!はすごい感動したなーとか、
初めてのPRが「[天の川への願い]霧矢 あおい」あおい姐さん推しの俺にふさわしいスタートだとか。
そういうことをふと思い返す。

そういう過去の出来事を思い返すという時点で、フォトカツというひとつの物語は俺の中で終わってしまったんだなって。終わってしまうしかないんだなって。

こういうゲームは、ゲームを思い出の中に置いておくしかなくて、そのときに感じていた気持ちを今の自分の状態でアップデートすることができないのがつらい。


好きだったソーシャルゲームの終焉を見た人は同じ気持ちだったのだろうか。



「フォトカツ」は終わったけど、まだ「アイカツ!」は続いていく。


【アイカツ!フォトonステージ!!】アイカツ!シリーズ5周年 特別楽曲「アイカツメロディ!」プロモーションムービー(フォトカツ!)



またどこかでフォトカツ*1と巡り合えたらと思う。


運営の人お疲れさまでした。
同じ業種なのでつながりにくいとかメンテ時の障害発生時のつらさは分かっているつもり。
閉塞作業が終わったので、しばらく休暇になるのだろうか。

次もいいサービスを配信してもらえればと思う。

*1:アイカツ!の新しいソーシャルゲームサービス

AWS認定ソリューションアーキテクト アソシエイト(2018年2月リリース版)の試験メモ

AWS 認定ソリューションアーキテクト – アソシエイト」の(2018 年 2 月リリース版)(SAA)を受けた!


そして落ちた!

f:id:snofra:20180710190424j:plain

合格ボーダー72%の51%なので全然足りてなかったっすね……。

言い訳ではないがSAAは旧版に比べて難易度が高くなったと言われている。
問題構成も旧版と異なっている。

f:id:snofra:20180710190548p:plain
AWS 認定ソリューションアーキテクト – アソシエイト | AWS

現在移行期間中(2018年8月12日くらいまで?)のため、SAAを受けるのであればネットに知見がかなりある旧版を素直に受けておいたほうがいいのかなと思う。

旧版の模擬テストも受けてみたけど、内容が全然違うように思った。旧版だと7割くらいとれていたので、旧版だったら受かってた説まである。

肌感覚ベースだけど、新版と旧版でどう違うのかっていう点をメモしておく。

SAA新旧での違い

まず、新版の模擬試験と本試験を受けてみた感想だと、旧版のような1つの機能について細かく知っておけばOKという問題はほぼないと言っていい。

新版の問題(というか問題文)は要件であり、ネットワーク構成を文字で記載される。
また、回答は要件を満たす機能や、その要件を採用した場合の影響を選択していくことになる。

ということもあり、AWSの試験で調べたときによく出てくる以下のようなサイトをとりあえずやっておけば的な考えは捨てたほうが良い。
ひとつの参考情報として腕試すのは全然やっていいと思う。

aws.koiwaclub.com


SAA新版のよく出てきた印象のある問題

新版の問題で多いなと思ったのが、以下6つ。

  1. Amazon VPC(というかNATゲートウェイとNATインスタンス
  2. Amazon SQS
  3. 各ストレージサービスの違い
  4. 各データベースサービスの違い
  5. Amazon EBSの各ボリュームタイプの違い
  6. Amazon EC2の各インスタンスファミリーの違い


Amazon VPC(というかNATゲートウェイとNATインスタンス

上にも書いた通り、問題文はネットワーク構成を文字で表現されるので、構成図を想像できないと何の話しているのかさっぱりだと思う。

VPCを使用しているセキュアな構成図は、想像できるようにしておいたほうがいい。

クロスアカウントの接続もあって、direct connectでいいよな?みたいな不安が残る回答もあったので、マイナーなところもきっちり抑えておくことが重要。

qiita.com

qiita.com

qiita.com


Amazon SQS

アプリケーションからDBに対してデータ送るけど、リクエスト数の課題があるみたいな問題が出されていたような気がするので、SQSはしっかり押さえたほうがいい。

正直これもSQSじゃね?みたいに思ってたところが間違っている可能性があるので、似たようなサービス(SNS)との違い等もしっかり押さえたほうがいい。*1


各ストレージサービスの違い

問題にどのストレージがいいのかみたいな問題が多かったので、それぞれの特徴(できることできないこと)はメモしておいたほうがいい。

回答にデータベース機能もあったんだがストレージ=データベースではないよな?さすがに


各データベースサービスの違い

ストレージと同じ。
サイズを自動で変更できるものは?とかKeyValue構成のものは?とかあったので、違いを一覧化していけばよいかなと。


Amazon EBSの各ボリュームタイプの違い

どちらかというと旧版よりの問題。汎用とIOPSの違いを訊かれる。というかほぼそのまんまな問題だった気がする。ボーナス問題。


Amazon EC2の各インスタンスファミリーの違い

EBSと同じ。これも比較的ボーナス問題。


その他

模擬試験を受けたときは、VPCのネットワーク構成よりもサーバーレスアーキテクチャ(というかLambda)について問われる問題が多く、新版はサーバレスアーキテクチャ重視になったのかなーと思ったら全然違った。

本試験はたまたまネットワークな問題が多かっただけなのかもしれない。
サーバーレスアーキテクチャな構成も確認したほうがいいと思う。


テスト勉強について

試験落ちているヤツのテスト勉強について聞いてもしょうがないと思うけど書いておく。

テスト勉強は以下3点を重点的に実施した。

  1. AWS Black Beltセミナー資料を読む
  2. 各機能のAWS ドキュメントを読む
  3. 書籍を読む

今考えるとこれにプラスして実機を触るっていうところはやっておいたほうがよかったなーって思う。
ただ、ネットワーク構成ちゃんとつくるの結構ハードル高いと思うのでそこは資料読むなりするしかないよなーと。

aws.amazon.com

AWS ドキュメント | AWS


書籍は以下3冊。
まずは「Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂版」を読んだほうがいいのかなと思う。

合格対策 AWS認定ソリューションアーキテクト -アソシエイト

合格対策 AWS認定ソリューションアーキテクト - アソシエイト

合格対策 AWS認定ソリューションアーキテクト - アソシエイト

実際、この書籍だけでは合格対策にはならない。この本は機能単位での説明であって、ネットワーク構成は語っていない書籍のため。
メジャー機能で知らないものがあれば、目を通しておけばふわっとした全体像がつかめるかなというレベル。


Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂版

Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂版

Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂版

「合格対策 AWS認定ソリューションアーキテクト -アソシエイト」よりもまずはこの本を読んでいくことをお薦めする。

改訂版でNATゲートウェイを使用しているので、そこを踏まえて何をやっているのかを一緒に組みながら見ていくのが良いかもしれない。


Amazon Web Servicesクラウドデザインパターン設計ガイド 改訂版

Amazon Web Services クラウドデザインパターン設計ガイド 改訂版

Amazon Web Services クラウドデザインパターン設計ガイド 改訂版

クラウドパターンとして各パターンごとのネットワーク構成が記載されているが、SAAを突破するという目標のみであればスコープ外なネットワーク構成が多いので、特筆して読む必要はない書籍かなと。

*1:さすがにSNSとの違いはわかった

【技術編】アイカツ!シリーズのCD売上から見えてくるもの

先週書いたアイカツ!のCD売上分析で使用したpytonコードをメモとして記載しておく。 分析自体については以下を参照ください。
snofra.hatenablog.com

今回のデータ分析について


f:id:snofra:20180611001537p:plain
今回はデータ量も大したことなかったので手動でデータをcsvに加工して作業をしていた。
JINの投稿データは収集に1時間かかってマジクソと思ったんだけど、クローラ作るほど何度もJINは利用しないので頑張った。

データの加工はpandasで簡単にやりつつ、描画はbokehにしてpandasのdataframeをそのまま取り込むことにした。

実装量はかなり少ない。変に自前でサマリする処理加えるよりも楽だったというのが正直なところ。


実装


ロード部

import pandas as pd
import numpy as np
import math
# bokeh系のライブラリ
from bokeh.plotting import figure, output_file, show
from bokeh.io import output_notebook
from bokeh.models import ColumnDataSource,  Range1d, LinearAxis
output_notebook()

# csvファイルのロード
# アイカツ!のCD売上
df_aikatsu_cd = pd.read_csv('C:/xxxx/cd_sales.csv', parse_dates=[2], engine='python', encoding="utf-8")
# googleTrends
df_trend = pd.read_csv('C:/xxxx/multiTimeline.csv', parse_dates=[0], engine='python', encoding="utf-8")
# JINのアイカツでヒットした投稿数
df_jin = pd.read_csv('C:/xxxx/jin.csv', parse_dates=[0], engine='python', encoding="utf-8")

sales_day_all = df_aikatsu_cd.fillna('0')


加工部

# 発売月単位でサマリする
df = pd.DataFrame({'発売月' : sales_day_all["発売日"].dt.strftime('%Y-%m'),
                   '初動枚数' : sales_day_all.fillna('0')["初動枚数"].str.replace(',','').astype('int'),
                   '累計枚数' : sales_day_all.fillna('0')["累計枚数"].str.replace(',','').astype('int'),
                   '売上高' : (sales_day_all.fillna('0')["セールス(円)"].str.replace(',','').astype('int') /10000).round(0) # 売上高(万円)単位で出すため除算
                  })

df_groupby = df.groupby("発売月",as_index=False).sum()

# 発売年単位でサマリする
df_groupby_year = pd.DataFrame({'発売年' : sales_day_all["発売日"].dt.strftime('%Y'),
                                '初動枚数' : sales_day_all.fillna('0')["初動枚数"].str.replace(',','').astype('int'),
                                '累計枚数' : sales_day_all.fillna('0')["累計枚数"].str.replace(',','').astype('int'),
                                '売上高' : (sales_day_all.fillna('0')["セールス(円)"].str.replace(',','').astype('int')/100000000).round(4) # 売上高(億円)単位で出すため除算 
                               })

df_groupby_year = df_groupby_year.groupby("発売年",as_index=False).sum()

# googleTrendsを月単位でサマリ
df_trend_month = pd.DataFrame({'月' : df_trend["週"].dt.strftime('%Y-%m'),
                               'トレンド数' : df_trend.fillna('0')["トレンド数"].astype('int')
                             })

df_groupby_trend = df_trend_month.groupby("月",as_index=False).sum()

# googleTrendsを年単位でサマリ
df_trend_year = pd.DataFrame({'年' : df_trend["週"].dt.strftime('%Y'),
                             'トレンド数' : df_trend.fillna('0')["トレンド数"].astype('int')
                             })

df_groupby_trend_year = df_trend_year.groupby("年",as_index=False).sum()


# JINのアイカツでヒットした投稿数のサマリ
df_jin = pd.DataFrame({'投稿月' : df_jin["投稿日"].dt.strftime('%Y-%m'),
                       'count' : df_jin.fillna('0')["count"].astype('int')
                      })

df_groupby_jin = df_jin.groupby("投稿月",as_index=False).sum()

年単位、月単位のサマリはDataframeでやるのが一番簡単かなということで、Pandasのdataframeのgroupbyとsum()で一気に集計している。

bokehの表示上の都合で、売上高の桁調整をここでやる。 0が多すぎるとうまく表示されない。

pandasのdataframeの一部カラムだけ表示したいなーと思って調べたので、今回は特に使うことないがメモだけしておく。

# pandasのdataframeの一部のカラムだけ表示する
print(df.loc[:,['発売月','初動枚数','累計枚数']])

f:id:snofra:20180610015241p:plain
こんな感じで表示される。


曲線近似の算出

# 曲線近似の算出
# 累計枚数
regression = np.polyfit(df_groupby.index, df_groupby['累計枚数'], 1)

print(df_groupby.index*regression[0] + regression[1])

# 売上高
regression_sales_amount = np.polyfit(df_groupby.index, df_groupby['売上高'], 1)

print(df_groupby.index*regression_sales_amount[0] + regression_sales_amount[1])

曲線近似の算出はnumpyとscipyがあるようだけど、今回はnumpyで実装。
ailaby.com
qiita.com

正直、曲線にする必要は全然なかった。
グラフのプロットはprint文のとおり、CD売上月とCDの累計売上数or売上高で1次関数で算出している。


グラフのplot

時系列データを使ったCD売上推移

# CD売上推移のグラフplot
df_groupby["発売月"] = pd.to_datetime(df_groupby["発売月"])

# CD売上のplot
p = figure(plot_width=800, plot_height=400, x_axis_type="datetime", title="CD売上推移")
p.line(df_groupby["発売月"], df_groupby['累計枚数'], line_width=3.5, color="red", alpha=0.5)
p.circle(df_groupby["発売月"], df_groupby['累計枚数'], fill_color="white", line_color="red", size=10)

# 曲線近似のplot
p.extra_y_ranges = {"graph2": Range1d(start=0, end=11200)}
p.line(df_groupby["発売月"], df_groupby.index*regression[0] + regression[1], line_width=1,color="blue", alpha=0.5, y_range_name="graph2")

show(p)

グラフのX軸と、y軸の説明、グラフの凡例は多少加工しているが以下のような感じで出力される。
f:id:snofra:20180529000900p:plain

かなりシンプルに実装できる。 Dataframeをそのままグラフにplotできるbokehだからこそのシンプルさだと思う。

苦戦したのはX軸をうまく読んでくれないというのがあった。
というのも時系列データにする場合、型をちゃんと日付型にする必要があったんだけど、daraframeでは文字列型だったから。
日付型にto_datetimeしてから再度入れなおすという対応をした。

盛り上がっていた時期を調べるグラフ

df_groupby_trend["月"] = pd.to_datetime(df_groupby_trend["月"])
p = figure(plot_width=800, plot_height=400, x_axis_type="datetime", title="盛り上がっていた時期は?")

# CD売上のplot
p.line(df_groupby["発売月"], df_groupby['累計枚数'], line_width=3.5, color="red", alpha=0.5)
p.circle(df_groupby["発売月"], df_groupby['累計枚数'], fill_color="white", line_color="red", size=10)

# googletrendsのplot
p.extra_y_ranges = {"graph2": Range1d(start=1, end=500)}
p.line(df_groupby_trend["月"], df_groupby_trend['トレンド数'], line_width=3.5, color="green", alpha=0.5, y_range_name="graph2")

show(p)

これもグラフのX軸と、y軸の説明、グラフの凡例は多少加工しているが以下のような感じで出力される。
f:id:snofra:20180530002546p:plain

JINとの比較グラフ

df_groupby_jin["投稿月"] = pd.to_datetime(df_groupby_jin["投稿月"])
p = figure(plot_width=800, plot_height=400, x_axis_type="datetime", title="GoogleTrendsの検索数vsJINの記事数")

# googletrendsのplot
df_groupby_trend["月"] = pd.to_datetime(df_groupby_trend["月"])
p.line(df_groupby_trend["月"], df_groupby_trend['トレンド数'], line_width=3.5, color="green", alpha=0.5)

# JINの投稿数のplot
p.extra_y_ranges = {"graph2": Range1d(start=0, end=20)}
p.line(df_groupby_jin["投稿月"], df_groupby_jin['count'], line_width=3.5, color="blue", alpha=0.5, y_range_name="graph2")
p.add_layout(LinearAxis(y_range_name="graph2"), 'right')

show(p)

基本は前のものと同じなんだけど、このグラフはグラフの右側にメモリを表示するようにした。メモリがあったほうが分かりやすいかなという判断。
p.add_layout(LinearAxis(y_range_name="graph2"), 'right')


折れ線グラフを棒グラフにしたパターンも試してみているので、メモしておく

df_groupby_trend["月"] = pd.to_datetime(df_groupby_trend["月"])
df_groupby_jin["投稿月"] = pd.to_datetime(df_groupby_jin["投稿月"])
p = figure(plot_width=800, plot_height=400, x_axis_type="datetime", title="GoogleTrendsの検索数vsJINの記事数")

# googletrendsのplot
p.line(df_groupby_trend["月"], df_groupby_trend['トレンド数'], line_width=3.5, color="green", alpha=0.5)

# JINの投稿数のplot
p.extra_y_ranges = {"graph2": Range1d(start=0, end=20)}
p.vbar(x=df_groupby_jin["投稿月"], width=1, bottom=0,
       top=df_groupby_jin['count'], color="blue", y_range_name="graph2")

show(p)

その場合はこのようにplotされる。
f:id:snofra:20180610024701p:plain

相関係数の算出

# 相関係数の算出
correlation = np.corrcoef(df_groupby_trend_year["トレンド数"].values.tolist(), df_groupby_year["累計枚数"].values.tolist())
print(correlation[0,1])

相関係数を出すために各dataframeをarrayにしている。 月単位も年単位も同じやろってことで年単位にしてる。

numpy.corrcoef — NumPy v1.14 Manual

f:id:snofra:20180610233329p:plain
相関係数0.75はまあまあ相関しているのかなーっと。

売上高の算出

p = figure(plot_width=800, plot_height=400, x_axis_type="datetime", title="CD売上高推移")

# 売上高のplot
p.line(df_groupby["発売月"], df_groupby['売上高'], line_width=3.5, color="red", alpha=0.5)
p.circle(df_groupby["発売月"], df_groupby['売上高'], fill_color="white", line_color="red", size=10)

# 曲線近似のplot
p.extra_y_ranges = {"graph2": Range1d(start=1000, end=2000)}
p.line(df_groupby["発売月"], df_groupby.index*regression_sales_amount[0] + regression_sales_amount[1], line_width=1,color="graph2", alpha=0.5, y_range_name="foo")

show(p)

グラフの実装は前と同じなので、言うことは特にない。
f:id:snofra:20180605001140p:plain


売上高の算出

# 年別売上高
#売上高でソートしてdataframeのindex振り直し
df_groupby_year_tmp = df_groupby_year.sort_values('売上高').reset_index(drop=True)

# 売上高のplot
p = figure(plot_width=400, plot_height=500, title="年別売上高")

p.hbar(y=df_groupby_year_tmp.index, height=0.5, left=0,
       right=df_groupby_year_tmp['売上高'], color="firebrick")

show(p)

plotするときにソートができそうになかったので、事前にソートを実施。
その時にdataframeのindexを振りなおさないと、結局plotしたときにソートが意味なくなってしまうので、dataframeのindexを振りなおして、y軸にindexを設定している。

ただこれをやるとy軸のメモリの凡例が0~6になるという問題があって、俺は結局グラフの加工でカバーすることにした。
うまい方法ないのかなー。
f:id:snofra:20180605004057p:plain


実装

簡単なplotなのでそんなに実装に時間はかかっていないけど、加工するのめんどい。
けど、加工したほうが見やすいっていうのをここのブログ見て理解した。

speakerdeck.com

shinyorke.hatenablog.com

今まではplotしてはいできたって、実装視点でしか見てなかったんだけど、実際はあれじゃわかりにくかったよなーと。
グラフ中に分かりやすく書いてあげるってのが必要だと思ってた。
気づかせてくれてありがとうございますっていう気持ち。

技術書典4で買った本

技術書典4が4月22日に開催された。もう1か月以上前なのか。
俺は北海道在住なのでなかなか行けないけど、今は以下のようなサイトで電子版として読めるんだからいい時代になった。

booth.pm

技術書典4で買った本をメモしておく。

  • 脆弱性ってなんだろう? 〜CVSSを知ろう〜
  • ソフトウェアエンジニアの情報収集について
  • WOWHoneypotの遊びかた


脆弱性ってなんだろう? 〜CVSSを知ろう〜

共通脆弱性評価システム(CVSS)の評価方法について漫画で紹介している本。CVSS V2ベース。
CVSSの評価方法いまいちわかっていなかったので、読んでよかった。

脆弱性を家の錠前に例えているので初心者の俺が読むにはちょうど良かった。


ソフトウェアエンジニアの情報収集について

エンジニアのいわゆるググりかたを教えてくれている本。

技術系の情報収集方法や、質問の仕方みたいなのも書いているので、ググり方よくわからないと1度でも思ったら目を通しておくのもいいかも。

質問の仕方については以下サイトがベース。かなり勉強になるので以下サイトを読んでおいて損なし。
技術系メーリングリストで質問するときのパターン・ランゲージ


WOWHoneypotの遊びかた

セキュリティの勉強のひとつとしてHoneypotを導入してみようと思って買った。

この資料がベースになっている。
speakerdeck.com

上記のほかに実際に導入する手順も入っているので、いざ入れようとなっても詰まらないんじゃないかなーと思う。


まだまだ読みたい本

まだ買っていないけど、読んでおきたい本もある。

技術書典でかなり有名なこれは買ったほうがいいかなと思ってる。DNS本。
booth.pm

あとはvvvv本。VJやってみたいなーって思っているので。
booth.pm

5月読んだ本

読んだ本の内容を忘れないようにメモしておく。
5月から今更kindleを使い始めて読書がはかどるようになってきた。
ただやっぱりデータより実物買ったほうが買った感あっていいよなー。

あと、簡単な感想はツイッターに書いたりしているのでそこから思い出すんだけど、まとめて書くとかなり時間がかかる。
次から1冊単位で書こう。


売る力 / 鈴木敏文

うちの会社のマーケティングチームから鈴木敏文氏の本は読んだほうが良いとの話を聞いて読んでみた。

セブン&アイ・ホールディングスを創り上げた人間の仕事術として、商品のどこをこだわったのかを軸に記載さてている本。

この本の主軸は変わらない視点に対して、いかに新しい要素を加えていくかという点。

ざっくり概要を書く。

新しいものをつくためには

新しいものを作るためには予定調和を壊す必要があるが、それは奇をてらったものでは一時的に話題になっても定着しない。

定着させるためには、変わらない視点に対しひとつアクセントを加えることで発生する、おやみたいなレベルの壊し方が重要。

一時的な爆発力よりも、客に期待を継続させ続けるということが必要。

この本では上質さと手軽さをx,y軸として置いたときにどこに誰も参入していない空白地帯を見つけるかというのが書かれている。

その軸のいずれかが、変わらない視点であってその軸を変えないことが肝要である。

二匹目のどじょうを狙うと大体うまくいかないので、それよりは現代の消費者が最も関心を持つだろう2つの座標軸の空白地帯を見つけること。

ビジネスの成功

ビジネスには運の要素がある程度あるが、運は自分がいかに呼び寄せるような一歩踏み込んだ挑戦や努力をしたかである。

自分がうまくいっていないと思う場合、運よりも自身が何かに縛られていたり、安易に妥協していて幸運と出会いにくい働きかたなのではないか。

畑違いでも観点は同じ

自分とは全然畑違いだが、自分が言われることや意識しようとしている観点が同じだなと思うことがあった。

特に変わらない視点に対して何を組み合わせていくかという点は、自分がどの分野で生きていくかを決めるときに役立つんじゃないかと思う。

自分の視点がない状態でプロジェクトにいた場合に、提案されるものに対してこうだという理由も出しにくいし、逆に言われたことに対する突込みも出てこない。

そういう点でいかに自分の変わらない観点を持つかっていうのは大切だし死ぬ程言われていることなので。


非社交的社交性 大人になるということ / 中島義道

中島義道を薦められたので、読んでみた。

全2部構成で1章が自身の半生を顧みるもの、2章が自身の主催する哲学塾にいる不思議な人たちについて書いたもの。エッセイみたいな本。

カントを研究している人なので、カントの哲学について書かれている。

自殺

その中で完全義務と不完全義務について書かれていて、自殺は楽になりたいという気持ちからくるのであれば、それは理性よりも快楽を求めるため完全義務に反するというのはなるほどなと思った。
qlocozy.com

他人を恐れる

他人を恐れる人は決まって他人による自分の評価を恐れる人、他人によく思われたいという気持ちが強い人である。
どうせと呟いて自暴自棄にならないためには、自分を評価する2つのいずれかの存在が必要。

  1. 自分のやっていることが認められること
  2. 自分を心から愛する人、評価する人、理解する人が存在すること

これはよくツイッターで言われるような承認欲求を満たすにはに該当する内容で、俺も承認欲求を満たされたいので、俺のやってることを誰か認めて理解してちやほやしてくださいw


最速の仕事術はプログラマーが知っている / 清水亮

最速の仕事術はプログラマーが知っている

最速の仕事術はプログラマーが知っている

有名プログラマ清水亮のライフハック本。
以下の5章で構成されている。

  1. 迅速で無駄のない仕事術
  2. 情報の整理術
  3. 致命的なミスを行わないための段取り方法
  4. チームの成果を最大化する
  5. 視野を広げてビジネスを設計する

内容としては筆者の経験を元にしながらtipsを各章5~10程度紹介する構成となっている。

迅速に作業を行えるための辞書登録しようやword使うな、情報収集に検索方法を工夫しろとか、情報整理にevernote使ったほうがいいというレベルのもの。

この本を読む人はきっと一般の人というよりはSEに寄っている、あるいは趣味でプログラム触っているひとみたいな感じなのだろうか。

おそらく一般の人が読むと読みにくい箇所もあるかもしれない。
ループの話をしたりプログラミング用語も多少出てくるので、なじみなければ読みにくいかもしれない。

SEの人が読むと2015年の本でもあるので、今更感のある話もあったりすると思う。ネットのライフハック系の記事で見知った内容もあるかもしれない。

読んでいて微妙だなって思ったのは、各章で人称にばらつきがあるという点。私だったり筆者だったり。そこは合わせてほしい。


こうすれば必ず人は動く / デール・カーネギー

『人を動かす』のほうが有名だと思うが、デール・カーネギーラジオ講座の書籍版。
『人を動かす』と同じかどうかは未読なので分からないけど、基本はおなじなのではと。

全23章に対し人を動かすためにはどのようにすべきか解説しつつ、ラジオドラマ形式のセリフページで再現する構成。

今も書店で平積みで置いていることの多いカーネギー本なので、いろいろ興味深く読めた。

ザクッとかく。

誤りを犯した場合

自分を守るためにも、まず間違いを犯したら、速やかに十分にそれを認める。

他人に間違いを伝える場合

他人が自分に協力したいと思わせるように、その人自身の間違いに気づかせる。

他人の前で叱責して辱められるとやり返そうとするだけ。
自分が扱ってもらいたいように他人を扱う。

その人自身の過ちを気づかせるのであれば、その人の感情を傷つけないようにそのその人の面目が保たれるように思いやりを持って行う必要がある。

自分自身に対しての気持ちの持ちよう

「自分のことを自分がどう思っているのか」が重要。

自分に勇気がなければ、今すぐに勇気を持つ。

胸を張って自分は強い人間であることを体を使って表現する。そうすることで次第に勇気が自分のものになる。

また自分で自分を蔑まない。それを相手の前で言わない。自分で自分を蔑むことで相手も自分を蔑むようになる。

自分のことを考えるのをやめる。
勇気が持てない理由の一つに他人が自分のことをどう思っているのかに対して恐怖心を持っているから。恐怖心は克服できる。

他人は自分のことなんて考えていない。
自分を見ているという感じはただの錯覚。

他人も自分と同様に自分のことしか考えていないし、自分と同じように他人が自分をどう思っているのか気にしている。

相手を味方につける

相手の興味について興味を示す。

自分のことではなく、相手のことについて話をすることで相手は何時間でもしてくれるし、そういう自分を気遣ってくれる相手に対して味方になる。

自分のことを忘れて無私の気持ちで興味・関心を抱くことで友人を作ろうと思わなくても友人ができる。

人から興味を持ってもらいたいと思うなら、人に対して興味を持つこと。

自分のことを考えることをやめ、自分がいかに素晴らしいのか語って大したものだと思われるようにしないことが重要。

自分が成功するためには

成功するためには自分に与えられた仕事を遂行するための脳力を決して疑わないこと。

実際にトライしてみると自分が思っている以上のことができる。

自分の年齢に誇りをもつ。
隠したり偽ったりせずに、歳を取ることによって培われる判断力、信頼性、経験があるということを確信する。

時間の使い方

自分が時間をどのように使っているのか、それを把握することが大切。

1日の計画を立てることによって、焦りと優柔不断という成功を妨げる要素を排除できる。
また、自分なりの目標を立てる。毎日、ある一定のことを成し遂げようと心に決める。

目標を立てることで、締め切りが発生してそれに間に合わせなければならないというときに最も大きな成果が上げられる。


情報セキュリティハンドブック

情報セキュリティハンドブック

情報セキュリティハンドブック

内閣府が無料に配布しているので読んでみた。
kindleで無料配布しているのと、内閣セキュリティセンター(NISC)でも無料配布している。

www.nisc.go.jp

全部で5章に分かれていてそれぞれ以下のとおり。

プロローグ サイバー攻撃ってなに?
第1章 基本のセキュリティ ~ステップバイステップでセキュリティを固めよう~
第2章 セキュリティを理解して、ネットを安全に使う
第3章 スマホ・パソコンのより進んだ使い方やトラブルの対処の仕方
第4章 被害に遭わないために、知らない間に加害者にならないために
第5章 自分を守る、家族を守る、災害に備える
エピローグ 来たるべき新世界

読んでほしい対象はセキュリティに対して知見のない人。
全編通してイラスト付きで説明しているので、とっつきやすいと思う。

本当にセキュリティのことを知らない人、一般の人は第2章から読むことをお勧めしたい。

第1章は、セキュリティを勉強したい人、基本情報試験の勉強している人は、最初の第一歩として読むのにはすごい適していると思うが、一般の人には難度が高い気がする。
途中でイラストがなくなるページも数ページ続くので、読むのがきついと思う。

セキュリティリスクの話をする本ということもあるからか、2章以降、基本的に物事を悲観的に見てることが多いので、ちょっとそこは気になった。

日経ネットワークの「インターネットができるまで」メモその2

日経ネットワーク2018年5月号の「インターネットができるまで」がよくまとまっており学びがあったので、学んだところをメモする。続き。

snofra.hatenablog.com


TCP/IP:データを小包に分けて送る

ここではTCPからTCP/IPへの変遷について記載されている。
TCP/IPについてはある程度の知識は持っているが、TCP時代の話は知らなかったので勉強になった。

TCPTCP/IP

1974年当初トランスポート層ネットワーク層は分割しておらず1つだった。それがTCP
1978年にトランスポート層(TCP)とネットワーク層(IP)が分割することになった。

その間4年なので結構短い。

なぜ分割されるようになったのか

TCPプロトコルTCPUDPかを判断することになるのだが、送信元と送信先間のみで必要なプロトコル

送信元と送信先間に存在するルータはこのプロトコルは不要というか、むしろ経路だけ確認すればいいルータにTCPなのかUDPなんて負荷がかかってしまうだけなので分断。

フラグメント処理

ルータはパケットのMTU(Maximum Transmission Unit)に合わせてパケットを分割(フラグメント処理)を行いつつ、送信先へ。
一度分割されたらマージされることはなく、送信元でパケットを結合してデータを取り出すことになる。


IPアドレス:みんなが自分だけの住所を持つ

IPアドレスについての歴史と、IPv4が枯渇しているということが記載されている。

IPアドレスの振り分け

IPは自分で好き勝手に割り当てられるものではなく、一元管理される。IANA(Internet Assigned Numbers Authority)(アイアナ)で管理していた。

だが、運用費用の一部を米国政府の研究費用に使われていたことが非難されて、1998年にICANN(Internet Corporation for Assigned Names and Numbers)(アイキャン)が設立。
IANAが担っていた役割は2000年にICAANに引き継がれた。

引継ぎまでに17年かかっているの意外に時間かかってるなあと。

クラスによる割り当てについて

クラスによる割り当てとCIDR(Classless Inter-Domain Routing)による割り当てがある。

CIDRってどんなのだったっけとかたまに超初心者感出しちゃうんだけど英語でみるとそのまま書いてるのね。
クラスによる割り当てとクラスじゃない割り当てってこと。略語の理解大事。

なぜCIDRが使われるのか

そもそもクラスはIPアドレスの分類のことを言う。
クラスによる割り当ては基本クラスA~C*1*2まである。

  • クラスAがネットワーク部8ビット。0.0.0.0~0.255.255.255
  • クラスBがネットワーク部16ビット。128.0.0.0~128.0.255.255
  • クラスCがネットワーク部24ビット。192.0.0.0~192.0.0.255

じゃあなんでわざわざクラスじゃない割り当てであるところのCIDRを使い始めたかというと、

アドレスクラスを用いたIPアドレス割り当てには問題が生じた。ほとんどのネットワーク(たとえばインターネットサービスプロバイダ)ではクラスAでは大きすぎ、クラスCでは小さすぎたため割り当ての要求がクラスBに集中したのである。クラスBの割り当てを受けたネットワークの中には65,534台のホスト(インターネットサービスプロバイダであれば接続ユーザー数)を同時にすべて接続することがまれであるネットワークも存在し、IPアドレスが無駄に消費されることになった。

IPアドレス - Wikipedia

クラスAだと割り当てられるIPアドレスの数って1677万721で、クラスBが6万5536、クラスCが256の固定値で絶妙に使いにくかったから。

小さいネットワークを作ろうと思ったときにクラスAだと多すぎて、そんなにIPアドレス使わないのに維持管理に余計な工数かかるので、まあ松竹梅の竹選んどこ的な感じでクラスBが使われることが多かった。

とはいえクラスAもBも無駄多いので、動的にネットワーク変えられないの?って思って誕生したのがCIDR。


IPv4の枯渇

上で書いたIPアドレスのことをIPv4って呼ぶが、その番号誰が割り当ててくれるのってICANNであり、日本だとAPNIC(Asia Pacific Network Information Centre)という地域インターネットレジストリ(RIR:Rogional Internet Registry)が割り当ててくれる。

日本はJPNICという国別インターネットレジストリ(NIR:National Internet Registry)に所属しているが、JAPANICはIPアドレスの在庫を持っていないので、APNICに払い出してもらうことになる。

そのIPv4はもう枯渇していて、2011年4月にIPアドレス在庫が枯渇している状態。
これからの話じゃなくてすでにないという。

f:id:snofra:20180523010702j:plain
IPv4アドレスの在庫枯渇に関して - JPNIC


とりあえずは企業から返却されたIPアドレスを使っているが、IoT時代でとにかくインターネットにつないどけば、機械学習とかで分析できるやろな感じなので余計に枯渇するよねって話。


たまに見る光回線なのにインターネットクソ遅い問題みたいなのは、IPv4の上限ギリギリでみんな使ってるから混んでいるという話もあったりする。

IPv6にすることで早くなるみたいなのって結局誰もIPv6使ってないからという話で、今は早いかもしれない。
www.itmedia.co.jp

IPv4やべえって話。

日経ネットワークの「インターネットができるまで」メモその1

日経ネットワーク2018年5月号の「インターネットができるまで」がよくまとまっており学びがあったので、学んだところをメモする。

構成としては以下となっている。

  1. プロローグ:たった4拠点から始まった
  2. TCP/IP:データを小包に分けて送る
  3. IPアドレス:みんなが自分だけの住所を持つ
  4. ルーティング:事故が起こったら道順を変える
  5. DNS:通信相手を名前で指定する
  6. Web:世界中で情報を共有する

1についてはインターネットの歴史、2~6についてはOSI参照モデルネットワーク層トランスポート層とアプリケーション層について書かれている。


プロローグ:たった4拠点から始まった

ここではインターネットの起源であるAPRANET*1についてと、回線交換とパケット交換の違いについて、現在のインターネットについて書かれている。


読んだ感想

回線交換とパケット交換の違いについてはイラストが分かりやすかった。

回線交換方式はひとつの端末が通信を独占してしまって、使ってないときもその通信回線が独占されっぱなしでもったいない。
だからデータをパケットという小さい範囲で区切って送れば無駄な時間なくなっていいんじゃないかみたいな考え方。
そうすることで異なる端末からパラレルで送信できるし、あて先が同じパケットを別経路で送ったっていい。冗長化も生まれてきた。

今までパケット交換方式のことは知っていたけど、回線交換方式を知っておくことで歴史の流れから特徴がうまくつかめた気がした。


輻輳について

輻輳というワードいつも忘れがちなのでしっかりメモしておく。

輻輳とは、さまざまな物が1カ所に集中することで、通信分野では、電話回線やインターネット回線にアクセスが集中することをいう。輻輳が起きると回線がつながりにくくなったり、集中した通信システムがダウンするといった現象が起きる。システムのダウンを避けるために、輻輳が起きそうになった場合には通信を制限する輻輳制御という措置が取られる

輻輳 | 用語集 | KDDI株式会社


俺たちがときどき感じてるネットつながんねえな感じが輻輳状態ということ。しっかり覚えておく。

でもって、輻輳に関連して、フロー制御と輻輳制御がある。ともにトランスポート層

フロー制御

データをパケットという塊で相手に送るが、送信側がパケットを投げまくるけど受信側がさばききれないという場合もある。
さばききれないと取りこぼしてしまうのでTCPの場合、後でもう1度再送してもらわないといけない。

イメージ的には工場のラインで、流れてくるものがすごい多かった場合そりゃさばけるわけない。だけど、さばかなきゃいけないので漏らしたものはあとでまた流しなおしてもらわなければいけない。

それって正直無駄。
なので、受信側が送信側に受信可能なデータサイズを送るようになっている。これがウィンドウサイズ。
このウィンドウサイズによって送る量をコントロールするっていうのがフロー制御。


輻輳制御

輻輳制御っていうのが、通信開始したときにじゃあパケット送るかって大量のデータを送り付けてもネットワークが混んでいる可能性がある。

2車線道路で道路が混雑しているときに2車線すべて使う車が来たとしたら、クソ迷惑。
それやめましょうねってTCPだとスロースタートというアルゴリズムで通信量は少なくしている。

また、何らかの原因でネットワークが混雑している可能性があるので、その時にも通信量を少し抑えましょうねっていうのが輻輳制御。

詳細は『マスタリングTCP/IP 入門編』を参照のこと

マスタリングTCP/IP 入門編 第5版

マスタリングTCP/IP 入門編 第5版


インターネットの歴史がいまいちわからなかったので整理

登場用語

まず用語。
ISPはInternet Service Providerの略。ドコモとかauとかのこと。
ISPはその規模によってTier1とTier2で分けられていた。日本のTier1はNTTコミュニケーションズのみ*2
Tier1とTier2の間はIX(Internet eXchange Point)がいる。ISP通しの中継をやっているもので、各プロバイダ間、プロバイダ(Tier2)とNTT(Tier1)の中継を行っている。*3


インターネットの歴史について

以前10年位前まではTire1とTire2で明確に階層構造となっており、Tire2同士の接続は無償で相互接続を行える(ピアリング)。Tire2からTire1に対しては了以金を支払って接続(トランジット)していた。

最近はこの階層後続が崩れ始めている状態。

原因は米グーグルや米Akamai、米Facebookなど大手のトラフィックを持つハイパージャイアントと呼ばれる企業がCDN(Contents Delivery Network)をやり始めたから。

CDNというのは、たくさんの人がインターネットを使うようになってアクセスも増えてくる。そうしたときに当然サーバにアクセスが集中するんだけど、輻輳制御とかいちいちやっていたのでは遅くてしょうがない。
なので、CDNとしてサーバを分散させたほうがアクセスが集中しないでいいよねっていう考え方。*4*5

ハイパージャイアントが何を変えたかというと、Tier2はわざわざ金払ってTier1にトランジットしなくても、グーグルとかAkamaiとかCDNに直接ピアリングでよくなったということ。

この点でいいところはピアリング、つまり金払わなくていいということ。ハイパージャイアントの収入はコンテンツホルダだったり広告費だったり。
逆にハイパージャイアントのネットワークが落ちた場合、ウェブサイトに接続できないという大規模障害は発生する可能性がある。

[参考]
https://www.janog.gr.jp/meeting/janog33/doc/janog33-traffic-kamei-1.pdf
大規模な接続障害、Googleが謝罪 「ネットワークの誤設定」原因 - ITmedia NEWS
大規模ネット障害になっても不思議じゃない?「BGP」の仕組みとリスク | 日経 xTECH(クロステック)


ながくなったので、次で「TCP/IP:データを小包に分けて送る」以降の学びをメモしていく。