【しがないラジオお便りコーナー】フィードバック紹介 & コメント 2018年8月分

shiganai.org

ラジオはお便り紹介が一番楽しいと思っているしがないラジオのパーソナリティのzuckeyです笑

フィードバック紹介の7月26日 ~ 8月25日分をまとめました。

6月26日 ~ 7月25日 分まではこちら blog.zuckey17.org

ぜひ見て、気になるエピソードがあれば聞いてみてください！

8月編スタート！！！

僕も rebuildfmを聞き始めたときは何年かかるんだ...と思ってましたが、意外といけました！進捗どうでしょう？ 通勤とか、家事の間に聞けるのがPodcastの良いところだと思います。

最近、あまり聞けていなかったバイリンガルニュースを聞けていなかったバックナンバーも聞いています！

bilingualnews.libsyn.com

ep2でも話しましたが、かくいう僕も、大学の研究室時代に先輩が書いたCのプログラムの定数をゴニョゴニョいじっていた時期にCを勉強しようと思い立ちましたが、ポインタでひたすら挫折していた思い出があります... あのときに忍耐力があれば変わっていたかもしれないと思うと、悔やまれます。

まさかPodcastの聞き方がわからない状態から3ヶ月後には出演しているとは、このときは思っても見なかったでしょう！ ご縁に感謝！ 次回の技術書典振り返りもしたいですね！

ともするとSESというだけでダメ認定されがちな昨今の流れですが、多種多様な技術範囲を経験できるという意味ですごくポジティブな意見を聞けるのもしがないラジオならではかなと思っています。

今年はgamiさんが何度もバズ記事を書いてましたね！ それが名刺代わりになっているだろうな、というところで僕もまだまだ頑張りたいです。

jumpei-ikegami.hatenablog.com

この記事はJavaScriptやそれを取り巻く技術に対して、gamiさんがどう考えているか、までわかるのでめちゃくちゃ良記事だと思いました。

また、中でもちらっと話していますが、名刺代わりのプロダクト、というのにチャレンジしたいですね。

僕もこの2018年、「強い」の定義でずっと悩んでいました。 結論、というわけでもないですが、このような記事を書きました。 同世代で活躍されている方が多い中、負けてられない、一緒に上がっていきたい、そのさまをしがないラジオで追っていけたら最高だと思っています。

blog.zuckey17.org

全然緊張されておらず、楽しい収録になりました！Morixさんありがとうございました！ このエピソードでインフラ勉強会界隈にしがないラジオが広まった感があります。

wp.infra-workshop.tech

そうですね！ 自分がちょっと詰まったことでも、ただ動作したログでも、発表すると他の人になにかメリットがあると思います。 その際に、動作した環境や、なぜそれをしたのかという動機なども一緒に発表するとわかりやすくて良い発表になる、それを知るのが成長なんだな、と最近振り返って思いました。

徹底よろしくおねがいいたします🙏

☓ ざっきー ☓ ぜっきー ○ ずっきー

「しがないラジオ駆動人生」という言葉を頂いて、泣きそうになった直後の写真です！ meetupでおあいしたときも話しましたが、その後のマネジメントの葛藤など聞きたいので、また出演お願いします！！

ぷぽさんのゲスト回を聞いて出演していただいたいけさんのゲスト回をぷぽさんが聞いていただけているとは！ 良い話！

パーソナリティの新卒時代の友人、みっつんのデザイン転職話。 非デザイナーからデザイナーに転職した話とそのときの分析が面白かったですね！ tech系Podcastでデザイナーの話が出ていたのは珍しいかなと思います！

僕も最近思うのは、エンジニア <=> マネージャーと行ったり来たりするのはできないのかなあと思っています。 今僕が働いているツクルバのエンジニアマネージャーの方は、いいバランスを取られている気がするので、そのへんもあって、僕の「強い」エンジニア像がブレたりしています笑*1

このあとEMFMというPodcastを解説されて破竹の勢いでリスナーを獲得されているゆのんさん。 ぜひいつかコラボを！！*2

anchor.fm

ある程度続くコミュニティだと内輪感が強くなりすぎることも多々あります。 それにならないようにできる限り配慮しているつもりですが、そうなっていたらぜひぜひ指摘ください〜！

ところで、『初代 Unity Ambassador』認定おめでとうございます 👏

「女子リスナーは手を上げてください。」で手を上げてくださった貴重なかた！ ありがとうございます！

強いエンジニアはなんなのか、問題、今年末の振り返りでそのへんを書こうと、ちょっとずつまとめております。 難しいですね。

soussuneのお二方！初Podcastコラボありがとうございました！

まだ最新の実装にできていない https://shiganai.org...年末年始にがんばります！！

まとめ

以上です！

明日は8月26日〜9月25日まで！

*1:いい傾向だと思いますが

*2:エンジニアリング組織論への招待、ひろきさんのサイン本持ってます

【しがないラジオお便りコーナー】フィードバック紹介 & コメント 2018年7月分

この記事は、#しがないラジオ Advent Calendar 2018 2の25日目ラストの記事です。

adventar.org

ラジオはお便り紹介が一番楽しいと思っています。zuckeyです笑 しがないラジオのパーソナリティをしています。

最近はゲスト回が多めでフィードバック紹介ができてなかったのです。そこでこのアドベントカレンダーを使って紹介しようと思います。

あまりにも多くなってしまったのでこれから6日間、6月25日を起点に半年分を1ヶ月区切りで紹介しようと思います。

ぜひ見て、気になるエピソードがあれば聞いてみてください！

7月編スタート！！！

SIerから転職することや今の会社で合わなければ転職を考えるのも一つの選択肢だ、ということをよく話しています。 piroさんは逆でずっと1社でやってこられた方、そういう方をゲストに招いて、逆の意見を聞けているのもしがないラジオの良いところかなと思います。

やはり長く業界におられるといろいろな経歴、職種も違えば携わっている業界も違う、絵も描く。 面白いお話を聞けました。

技術系の職種で入社からの総務への社内異動、はじめは戸惑いながらもエンジニアリング観点で業務改善をされた話は僕もよく自分の周りの人との間で話題に上げてしまいます。

僕も最近またポモドーロを会社でやっているのですが、止められること前提でいると、本当に止めないと行けないものとそうでないものを判断しよう、という気持ちになってくるので、より良い感じに進捗できるようになった気がします！ あと、その場で適当に人に振れる力もついた気がします！

ちょっと何言ってるかわからないです。

ちょっと何（ry

はやみねかおるです！！ 最高ですよね！（急にテンションを上げる）

まず目的から述べている本、というだけでは漫画技術書に限った話ではなかったのですが、そこに主人公の立場も付け加えると、動機づけまでされて良いですよね。

日経Linuxデビューした記念すべきTweetです笑

しがないラジオの特徴として、ゲストで一番多いのが僕らと同世代（僕は1991年生まれ）、というのがありその世代が聞くとエモが爆発する、と言われています笑

Podcastは脱線が命だと思ってます。 脱線するからこそ深い話が聞ける。 長くなるのは許してください 🙏

あとのエピソードでもでてきますが、日本人は英語をちゃんと使いたい欲求が強いんですよね... ただ、最近気づいたのは、英語力が大学入学時からどんどん下がっているので、そろそろもうちょっと頑張らないといけないです。 とはいえ、OSSにバリバリ貢献されている方がこういう発言をしてくださるのはすごく後押しになると思います！

清水さん！ありがとうございました！ 来年はまたWe Are JavaScripters!に行きます！

wajs.connpass.com

今年はあえてあまり勉強会に参加しなかったのですが、勉強会中にメモをとって終わり次第即ブログにするのは、主催者にとってもいいですし、ビュー数が伸びるという意味で自分にとってもすごくメリットがあると思います。

ぽやぽやしたい。 ひらがなですよね笑

さすがOJTでしがないラジオを紹介される会社らしいです笑 参考 しがないラジオmeetup2

sp33 sp44 にも出演されています！！

言語を軽く触る意識してフィボナッチとかを書いて見るようになりました！ その後、電卓を言われてましたが難しいんですよね... その間がないものか...

投資、なるほどもっと引いて見ないといけないですよね〜。 楽しそうだな！っていうところに飛びついて、それでたのしかった〜ってなっていることが多いので、まだまだこれからですが、考えさせられます。

いつもはあまり出さないですが、gamiさんはブラックなのです（ゲス顔）

おっしゃる通りで先人の功績に感謝しつつ、それにおんぶにだっこで良いものを作っていきたい所存です！！ そして、自分でもいろいろなOSSに貢献されている桑原さん、尊敬します。何か僕もやらねば、同世代で焦ります。

「しがあるラジオ」ゲスト出演希望待ってます笑

現時点（2018-12-25）最新回でRedhatのサポートエンジニア、ひよこ大佐さんの話を聞いていますが、世間でのサポートエンジニアの認識と現実にギャップがあるようです。 もっとたくさんの方の働き方を聞いていきたいと思いました。

「あとで直す。」というのの他に、Issueにして放置っていうのがよくあって最近それをいかに無くすか（自分含め）というのでいろいろ悩んでいます。 なにかうまい知見あれば教えていただきたいです！

COBOLは一大コンテンツ！

最近Scrapbox使い始めて、わかばちゃんのわかりやすさに感激しました笑

しがないラジオはちゃんとコンバージョンにも貢献しています。 もし、なにか宣伝したい本やイベントなどがあれば、ぜひDM下さい笑

twitter.com

いろいろな人の紆余曲折って、あとからこじつけで話されることも多いと思っていて、そのへんFindyのCTOまさたんさんはすごく赤裸々に面白い経歴を話してくださり、最高にいい方でした！

まとめ

以上です！

明日は7月26日〜8月25日まで！

しがないラジオで2年弱パーソナリティをつとめ、53人のゲストと話をして感じた「ゲスト駆動の成長」

この記事は、#しがないラジオ Advent Calendar 2018の1日目の記事です。

shiganai.connpass.com

しがないラジオというPodcastのパーソナリティをgamiと2人でやっております。 そのオフ会兼勉強会兼忘年会みたいなものを開催しました。

お越しいただいた方々本当にありがとうございました。 リスナーが可視化されづらいと言われるPodcastで、たくさんのリスナーの方々と交流できるのは本当に嬉しいことだなと思いました。

本当に幸せな空間でした。

詳細については、この記事の最後に参加者の方々のブログへのリンクを記載するのでそちらを読むと当日の雰囲気がわかるかと思います。

ゲスト駆動の成長

当日は僕自身もLTをしたのですが、発表資料を作り込む余裕がなく、文字だけの簡素な資料になってしまったので、共有はしませんでした。
この記事では、スライド公開の代わりにそのLTの内容について書こうと思います。

これまでにないチャレンジが人を大いなる成長に導く

皆さんは普段Podcastを聞かれるでしょうか？僕は日々たくさんのPodcastを聞いているのですが、その中で以下の2つのエピソードが最近すごく心に残りました。

以下のブログには、これまでにないチャレンジを重視するような機械学習の新たな学習モデルが、既存のモデルよりも優秀な結果を残した、というような研究結果が記されています。 上記のエピソードはともに、その研究結果に人間の成長を重ねて議論を展開しています。

blog.openai.com

(日本語記事としてはこちらがありました 👉 予測ベースの報酬による強化学習でAIが高難易度の死にゲーで人間以上のハイスコアをたたき出す - GIGAZINE)

新たな学習モデル？

記事についてもう少し補足します。

スコアを競い合うような種類のゲームにおいて、機械学習を用いてそのスコアを上げるという研究があります。
どういった行動に高い報酬を与えるのか、ということを予測モデルに設定することで、学習をチューニングします。

これまでは「スコアが上がるような行動をとること」を重要視するようにしていました。
このような設定では、機械はスコアが上がるように行動しようとします。
しかしながら、その設定では人間がゲームをしたときの平均以下までしかスコアが上がらなかったということのようです。

次に、「新しいチャレンジをすること」「新しい状態になること」を重要視するようにしたようです。 すると、こちらのほうがスコアが上がり、人間のスコアを上回るようになったというのです。

人の成長にも新たなチャレンジが必要だよね

先程あげた両Podcastエピソードはマネジメントや組織論の文脈だったため、上記のような研究結果をうけて、プロジェクトや業務の過程の中でチャレンジを重視して評価したほうが、より評価の対象者は成長するのではないか、という話が展開していました。

大きなものを成し遂げるには、既存の方法だけではうまくいかないこともある。 新しいことをやることが目的になってはいけないが、既存にとらわれずゼロベースで考えられる力をつけるのが必要、ということでした。

成果物ベースよりチャレンジベースのほうが学習効率が良い、という話にもなっていました。

これはマネジメントだけでなく個人の成長にも同様のことが言えるのではないかと僕は思いました。

強いエンジニアになりたい

僕はPodcastでもそれ以外でもいろいろなところで「強いエンジニアになりたい」というようなことを言ってきました。 僕自信が後発のエンジニアで、界隈で有名だったり一目置かれたりするエンジニアに対して強く憧れを持っている、ということの現れです。

強いエンジニアってなに？

じゃあ、お前のいう強いエンジニアとはなんなのか？というのは、よく質問されることです。 特に2018年、年始に目標として強いエンジニアという言葉を出してからそれについてはいろいろと考えてきました。

LT中でも、

のような指摘をうけました。

本当にそのとおりで、強いエンジニアというのはなんなのか、最近特にわからなくなってしまいました。
本を書いたらすごいのか、大きい会社にいたらすごいのか、給料をたくさんもらったらすごいのか、わからないです。

結果として、「自分がどうなれば自分に納得できるのだろう？というのを突き詰めたい」ということなのだな、と考えるようになりました。

※ 強い/弱いというな表現について、インターネット上で賛否あることは理解しています。
「強さ」というのは相対的なものになってしまう部分はあると思います。
じゃあそれによって態度をかえたり、そういうためのものさしとして利用しようとしたりしているわけではないです。
純粋に「自分がどうなれば自分に納得できるのだろう？というのを突き詰めたい」という思いがあるのだと、理解いただけると嬉しいです。

様々な刺激によるランダムなチャレンジ

さて、冒頭にも述べたとおり、僕はしがないラジオというPodcastのパーソナリティをしています。
しがないラジオではゲストを呼んでその方が日々どのように考え、どのような工夫を経て、楽しく働いているか、楽しく生活しているか、ということを伺っています。
現在、未公開の分も含めると 53 人の方々とともに収録しました。
短い人では1時間半から長い方では4時間以上にもおよぶ収録をしています。

ゲストから刺激を受け、それを試す

ゲストの方々は、僕が出会ったこともないたくさんの難しい課題に取り組んでおられます。 それらについての話は、ノウハウの塊です。

その方々の口からでた本を読んでみたり、それについてチームのメンバーと話したりもしました。 そして、自分の日々の業務のルーティンをを一気にガラッと変えてみたりもしました。

これがいわゆる新たなチャレンジで、自分自身を新しい状態にしているのではないかなと思います。

そのすべてがうまくいったわけではないです。 けれども、長い目でみるとただただ、がむしゃらに時間と労力をかけてやっているよりも、結果としてより良い方向に向いているような気持ちになっています。

それが結果として、強いエンジニアにつながる道なのではないかと思うようになりました。

なのでこれからも刺激をくださるゲストに、楽しい挑戦の話をたくさん聞いていけたらなと思います。

まとめ

ゲスト駆動の成長について考えていたことを書きました。
リスナーの方々も同じように考えてくださってるのではないかな、と勝手に思っています。
そんな思いで、しがないラジオで発信したい、という方はぜひお声がけください。

これからもよろしくお願いします！！！

#しがないラジオmeetup2の感想ブログリンク集

（2018-12-01 時点で公開されていたもの）

note.mu

blog.vtryo.me

fortegp05.hatenablog.com

mzryuka.hatenablog.jp

皆様ありがとうございました！！

GitHubのIssueテンプレートを導入する方法のメモ

f:id:zuckey_17:20181119000127p:plain

個人のプロジェクトを立ち上げるのに、少数ですが複数人でプロジェクトを進めるため、Issueでタスクや機能の詳細を管理しようということになりました。

とはいえ、あまり一緒に仕事を進めたことも多くなく、テンプレートを導入することにしました。

自分でやったことがなかったので、メモとして残しておこうと思います。

必要なことは以下でした。

  • /.github/ISSUE_TEMPLATE以下にmarkdownファイルを置く
  • nameとaboutを入れる

f:id:zuckey_17:20181119000136p:plain

追加したテンプレートは以下でした。

bag_report.md

---
name: Bug report
about: バグを知らせてね

---

## 🐛 Summary

(バグの概要)

## 👀 Steps

(バグの再現手順)

1. Do action
2. Do another action
3. Wrong Behavior !!

## 🆗 Expected

(Closed になるために必要な状態)

## 🚑 Actual

(Issue を作成した時点の状態)

## 📎 Images (optional)

(バグ発生時の画像)

feature.md

---
name: Feature request
about: ワクワクするような新機能リクエスト

---

## 🎉 Goal

(Closed になるために必要な状態)

## 💪 Motivation

(Issue を何故立てたのですか？)
(Issue を作成した背景は？)

## 📖 Reference (optional)

(参考リンクなどあれば)

## 📆 Schedule (optional)

(Closed になるまでのスケジュール)

## 📎 Tasks (optional)

- [ ] Task 1
- [ ] Task 2

task.md

---
name: Task
about: タスクの整理と内容を記す

---

## 💪 タスク

### 📄 資料
+ 

### ✅ 作業
+ [ ] 

### 🚀 完了条件
+

絵文字を入れて楽しげにすることを意識しました。 （今週は短いですが、以上です）

Pythonで駅コード調査用データベースから情報をスクレイピングした

blog.zuckey17.org

前回、 Suicaの利用履歴をパースするリポジトリ中の StationCode.csvについて、

StationCode.csvがコミュニティーの有志によって作成されたものらしく、最新のものではないのか、完全ではないようです。

と書きました。

よくよく調べると、路線・駅コード一覧・登録 というサイトがあり、

路線・駅コード一覧・登録のページに遷移すると、駅コードのデータベースのようなものにたどり着きます。 ここで随時更新されているようなので、今回はこれをスクレイピングして、真・StationCode.csvを作成してみました。

Pythonによるスクレイピング、ちゃんとするのが初めてでいろいろハマりましたが以下のようなコードになりました。

import csv
import re
import urllib2
from bs4 import BeautifulSoup

current_page = 1

html = urllib2.urlopen("http://www.denno.net/SFCardFan/index.php")
soup = BeautifulSoup(html, "html.parser")
last_page_num = int(re.findall('[\d]+', soup.find("a", title="last page").string)[0])

file = open('StationCode.csv', 'w')

for num in range(last_page_num):
    html = urllib2.urlopen("http://www.denno.net/SFCardFan/index.php?pageID=" + str(current_page))
    soup = BeautifulSoup(html, "html.parser")
    rows = soup.find_all("table")[1].find_all("tr")
    del rows[0:2]
    for row in rows:
        datas = map(lambda x: not(isinstance(x, type(None))) and not(isinstance(x.string, type(None))) and x.string.encode('utf-8'), row.find_all("td")) # エンコード変換
        writer = csv.writer(file, lineterminator='\n')
        writer.writerow(datas)
    current_page += 1

file.close()

ファイルに書き出す際に UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128) と文字エンコードで怒られたので、空文字列でない場合にUTF-8にエンコードを変換する処理を書きました。

それ以外は意外とスムーズに進んだので、pythonすげーとなりました。

まとめ

周辺知識なしからSuicaの利用履歴を読み込むデモ（ macOS ）

f:id:zuckey_17:20181104184308j:plain:w200

Suicaの利用履歴を読み込み、入場駅やためていたデータの履歴を表示するところまでをとりあえずやってみたので、手順をまとめておきます。

お願い

僕はPythonをほとんど触ったことがないので、ライブラリの利用方法や読み込みなどあまり理解していないので、温かい目でみていただき、間違った部分があれば指摘していただければ嬉しいです。

用意するもの

ソニー SONY 非接触ICカードリーダー/ライター PaSoRi RC-S380

ソニー SONY 非接触ICカードリーダー/ライター PaSoRi RC-S380

PaSoRiはICカードリーダーでよく見るのでこれにしてみました。

nfcpy

今回は nfcpyというライブラリを利用します。

https://nfcpy.readthedocs.io/en/latest/index.html

NFC（Near Field Communication）で受け取った生データを読み込んで出力するためのライブラリのようです。

こちらを使います。

python3.x系への対応はまだらしく、2.x系を利用します。

python & pipの準備

僕はHomebrewにてpython2系をインストールしました。

$ brew install python@2
...(略)...

$ which python2
/usr/local/bin/python2

$ which pip2
/usr/local/bin/pip2

pip（pythonのパッケージ管理ツール）も一緒に入ります。

その他の必要な環境を準備

USB読み込み系

PaSoRiはUSBデバイスなのでそれを扱うためのライブラリをインストールしておきます。

$ brew install libusb
$ brew install libusb-compat
$ sudo pip2 install pyusb libusb1 pyserial

OpenSSL を新しくする

macOSに標準で入っているOpenSSLはバージョンが古いらしく、下記の方法で新しくします。

$ brew install openssl
$ ln -s /usr/local/opt/openssl/bin/openssl /usr/local/bin/openssl
$ ln -s /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib /usr/local/lib/libcrypto.dylib
$ ln -s /usr/local/opt/openssl/lib/libssl.1.0.0.dylib /usr/local/lib/libssl.dylib

バージョン管理ツールBazaar

nfcpy を利用するための方法は、 Bazaarというgitのような分散型のバージョン管理ツールを利用することが公式で紹介されています。 このツールはHomebrewで入れることができます。

$ brew install bzr

nfcpyを利用する

まず、Bazaarでnfcpyを落とします。 trunkというディレクトリにnfcpyのライブラリのリポジトリが落とせます。

$ bzr branch lp:nfcpy trunk
$ cd trunk
$ tree -L 1
.
├── HISTORY.rst
├── LICENSE
├── README.rst
├── docs
├── examples
├── nfc
├── setup.py
├── tests
└── tools

examples以下にこのライブラリを用いたサンプルがあるので、実行してみます。 まず先にmacにPaSoRiを接続しておきましょう。

$ python2 examples/tagtool.py
[nfc.clf] searching for reader on path usb
[nfc.clf] using SONY RC-S380/P NFC Port-100 v1.11 at usb:020:025
** waiting for a tag ** <<< ここで入力待ちをするのでICカードをPaSoRiに近づけます
Type3Tag 'FeliCa Standard (RC-S???)' ID=**************** PMM=**************** SYS=0003

これでFeliCa対応のカードの情報を取得することができました。 ↑は

  • IDm (製造ID/Manufacture ID)
  • PMm (製造パラメータ/Manufacture Parameter)

だそうです。

Suicaの利用履歴を読み込む

さて、本題のSuicaの利用履歴です。Suicaは過去20件の利用履歴が取り出せるようになっています。 nfcpyを利用してSuicaの情報を取得し、生データをパースして見やすくしてくれているライブラリが以下です。

https://github.com/m2wasabi/nfcpy-suica-sample

中を見ていただければわかりますが、StationCode.csvというところに、生データと駅との組み合わせがあり、それによって入出場駅を出力できているようです。

clone

このリポジトリを任意の場所にcloneし、中でnfcpyを落としてきます。 その際ディレクトリ名をnfcpyにしているのを間違えないようにします。

$ git clone git@github.com:m2wasabi/nfcpy-suica-sample.git
Cloning into 'nfcpy-suica-sample'...
remote: Enumerating objects: 13, done.
remote: Counting objects: 100% (13/13), done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 13 (delta 3), reused 13 (delta 3), pack-reused 0
Receiving objects: 100% (13/13), 65.33 KiB | 484.00 KiB/s, done.
Resolving deltas: 100% (3/3), done.

$ cd nfcpy-suica-sample
$ bzr branch lp:nfcpy nfcpy # ディレクトリ名をnfcpyに
Not checking SSL certificate for xmlrpc.launchpad.net.
You have not informed bzr of your Launchpad ID, and you must do this to
write to Launchpad or access private data.  See "bzr help launchpad-login".
Branched 284 revisions.

そして、直下あるsuica_read.pyを実行します。

python2 suica_read.py
Type3Tag 'FeliCa Standard (RC-S???)' ID=**************** PMM=**************** SYS=0003
=== 00 ===
端末種: None
処理: 物販
日付: 18-11-02
入線区: None-None
入駅順: None
出線区: None-None
出駅順: None
残高: 1734
BIN:
c7 46 00 00 25 62 6e a7 d0 59 c6 06 00 03 4a 00
=== 01 ===
端末種: 改札機
処理: 運賃支払
日付: 18-11-01
入線区: *********
入駅順: ***
出線区: *********
出駅順: ***
残高: 2643
BIN:
16 01 00 02 25 61 e0 09 e4 3e 53 0a 00 03 49 00

...（略）...

=== 19 ===
端末種: 改札機
処理: None
日付: 18-10-25
入線区: *******
入駅順: ***
出線区: *******
出駅順: **
残高: 3958
BIN:
16 14 02 01 25 59 ce 25 00 00 76 0f 00 03 31 00

と20件のSuica利用履歴が出力されました。 端末機: 物販などはコンビニで利用したときのもののようです。 また、 StationCode.csvがコミュニティーの有志によって作成されたものらしく、最新のものではないのか、完全ではないようです。

まとめ

  • Suicaの利用履歴が読み込めました
  • Pythonのエコシステムについて詳しくなかったためハマりました
  • Raspberry Piを購入したのでこれを使って楽しめたらなというのが今後の展望です

パブリックなページのpathにidを入れるかどうか検討した

パブリックなページのpathにidを入れるかどうか検討しました。
idといっても、DBのプライマリ・キーという意味なので以降 idというのはその意味で見てほしいです。

調べてみても案外エントリがなかったので書いておいておこうと思いました。
もしかしたら、間違っていたり考慮が足りなかったりすると思うので、そのときはコメントなどで教えてほしいです。

idを使う場合と使わない場合？

idを使わない場合

ユーザー個別のリソースを作成するページ

ユーザー個別のリソースに対する編集や削除などが他のユーザーからできてはいけません。
そういった場合は認証をかけると思いますが、単純にユーザーが登録などをしていない場合にも、ユーザー個別のリソースを作成したい場合があります。
何らかの質問項目に回答をしてもらう際などがそうです。（アパレルショップなどで経験があります。）
直接やメールなどでそのURLを送信することもありますが、その際、別の人がそのページを踏んでしまうと回答が混線してしまって大変なことになるので、避けるためにハッシュのようなものをidの代わりに利用することが多いです。

SEOや見た目を重視する場合

ユーザーフレンドリーなURLにすることはSEOにプラスに働くと言われています。
また、URLがわかりやすいとそのページがどういうものなのかを想像しやすく、またイトの世界観を壊さないために数字よりも意味のある文字列にすることもあります。

そのリソースの規模やKPIを悟られたくない場合

idがインクリメントであるならばリソースの数がそのままidとなります。
そのため、サービスの規模を隠したい場合などには隠すことが有効な手段というふうに考えられます。（ブログサービスの記事数など）
また、毎日のように新しいリソースを作るようにするとサービスの成長具合もわかってしまうこともあります。
そのことによって、KPIを推測されるというリスクもあり、それを避けるためにも有効な手段です。

idを使う場合

簡単に言うと上記以外なのですが、認証などはあるものの、個々のユーザーに関係なく同様のリソースを表現している場合です。
Railsなどのフレームワークでは複数存在するリソースに対してルーティングを作成するとデフォルトでidによってアクセスできるpathを用意してくれたりします。
not availableなリソースにアクセスした場合は、どちらの場合も404を返すようにします。
そのような前提に立つならば特に理由のない場合、ハッシュ化する意味はないように思いました。

参考にしたページ

connpass

https://shiganai.connpass.com/event/82050/

eventはすべてのconnpassユーザーが参照可能。

gitHub

https://github.com/rails/rails/issues/34300

Railsはパブリックなリポジトリなのでissuesはすべての人が参照可能。

はてなブログ

https://blog.zuckey17.org/entry/2018/10/21/140909

はてなブログは見た目重視で、デフォルトでは投稿日付をエントリへのパスにしてくれます。
またユーザーが個別にエントリへのパスを指定することもできます。

note.mu

https://note.mu/ruiu/n/n76729d8930c9

詳しく使ったことがないのでわからないですが、noteでは記事に投げ銭ができたり、購入機能があるためidをハッシュ化しているのだと思いました。 また、ブログサービスということで全体の記事数を隠したいという意図もあるのかもしれません。

まとめ

  • これまで深く考えたことがなかったのですが、仕事で必要になり少し意識的に詳しく調べてみました
  • 調査の際、相談にのってもらった方々ありがとうございました

冒頭にも書きましたが、間違っていたり考慮漏れたりしている可能性もあると思うので、コメントなどで指摘いただけると嬉しいです！！