駆け出しエンジニアの作業ノート

駆け出しエンジニアが作業ノート風にまとめるページ(関係無い事もしばしば)

networkxで最長片道切符のルートを算出しようとするが…

今回は、networkxというライブラリを使って最長片道切符を出そうとしたという記事です。以前使用したGraphillionでは、容量が大きすぎて計算が不能となるケースがありました。そこで、今回はnetworkxというライブラリを使って計算を実行してみました。コードは以下のようになります。

 

file1 = "honshu_networkx.txt"

Graph = nx.Graph()

def station_pick(lines):
station_list = []
for line in lines:
dat = line.split(",")
for i in range(2):
station = dat[i]
if station not in station_list:
station_list.append(station)
return station_list

def count_distance(path, edges):
distance = 0
f1_2 = open(file1, "r")
lines = f1_2.readlines()
f1_2.close()
for i in range(len(path)-1):
word1 = path[i] + "," + path[i+1]
word2 = path[i+1] + "," + path[i]
for line in lines:
if word1 in line or word2 in line:
dat = line.split(",")
distance += float(dat[2])
return distance

f1 = open(file1,"r")
lines = f1.readlines()
station_list = station_pick(lines)
f1.close()
edge1 = []
edge2 = []
for line in lines:
dat = line.split(",")
data1 = (dat[0], dat[1])
data2 = (dat[0], dat[1], float(dat[2]))
edge1.append(data1)
edge2.append(data2)

Graph.add_nodes_from(station_list)
Graph.add_weighted_edges_from(edge2)
longest_distance = 0
for path in nx.all_simple_paths(Graph, source='新青森', target='門司'):
all_distance = count_distance(path, edge2)
if longest_distance < all_distance:
print(path)
print(all_distance)
longest_distance = all_distance
else:
continue

 

 

データセットについては自作をしました。なぜ、これを用いたかというとGraphillionの作者の方が大きなデータセットの場合にnetworkxの使用を薦めていたからからと思ったのですが、ちょっとミスリードだった気がしてきました。

 

github.com

 

結果として、networkxの使用はあまり向かない気がします。理由としては最初に経路をを算出してから徐々に最長の経路を算出していきますが、例えば、大阪から門司の最長経路を出す際に、既に鳥取から門司までの最長経路が出ているにも関わらずもう一度再計算しようとする印象を受けました。計算に無駄が多いため、結局約2日掛けても終わりませんでした。

「サービス品質向上しナイト ~みんなでテスト!10年続くチームと品質~」に行ってきました

2月14日に「サービス品質向上しナイト ~みんなでテスト!10年続くチームと品質~」という勉強会があったので行ってきました。

 

willgate.connpass.com

 

主催者のウィルゲートさんのイベントには既に2回ほどお邪魔させて頂いております。

 

www.willgate.co.jp

 

品質向上という事で、運用と新機能開発のバランスや技術的負債の解消といった話があるのかと思いましたが、主にQAエンジニアに関するお話でした。

 

そもそもQAという考えには自分の会社には無く、初めて知る概念でした。テストを専門に行う部署があればより実装に時間を掛ける事が出来、開発効率が上がるのかなと思いました。ただ、今日になってこんなニュースもあったので、また変わっていくのかなとも思いました。

 

thebridge.jp

 

その一方で、取引先との問い合わせの1次請けや、要件定義の支援をするサポートチームがほかの会社には無いなど思わぬ形で自分の会社の良い文化を実感する事が出来ました。また、自分では慣れていた1開発1チケット制もほかの会社には無いところもあるようでした。

 

会社の文化が段々と把握出来てきたので、今後も他社さんの勉強会に行って他社さんの文化を知ってみようと思います。

ブログ1周年

このブログは初めての記事を投稿してから1年になりました。

 

というわけで、ちょっと振り返りをしたい思います。

 

 

はてなブログでは、外部流入によるアクセス状況を管理画面から参照出来るので、そのデータに基づき1番見られた記事を発表します。

 

1番はこの記事でした。

 

psyduck-take-it-easy.hatenablog.com

 

こちらの記事はほかの記事を抑えてダントツの1位でした。こちらの記事に関しては公開直後よりも時間が経ってから、リアクションを頂いています。リアクションについては、私の励みになりますので、今後も寄せて頂ければと思います。

 

最長片道切符については、今年は少なくとも1回、もしかすると2回本州側で路線の開業があるため、変化する可能性があります。特に、今年の12月に開業すると噂の相鉄新横浜線埼京線(ほぼ確定)の直通運転の際に、鶴見-羽沢横浜国大(横浜羽沢)間の営業キロの設定だけで無く、現在一部ライナーが運行されている東戸塚-横浜羽沢間の営業キロが設定されるのかが気になっています。

 

仮に設定された場合、東北仙石ライン開業のようにルートがかなり複雑化する可能性があります。

 

また、JRが関係する新線の話ではこんなニュースもありました。

 

headlines.yahoo.co.jp

 

こちらの新線についても、開業すれば最長片道切符に関わってくる事が容易に想像出来るので、運賃計算上のルートがどのようになるか楽しみです。

 

では、今後とも、本ブログをよろしくお願いします。

技術書典に出展します

2019年最初の記事となります。

4月14日に池袋サンシャインシティで開催される技術書典6に出展します。以前、1回訪問した事がありますが、今回は執筆者側として参加します。共同サークルなので、サークル主という立場ではありませんが参加させて頂きます。

 

techbookfest.org

 

内容については、Pythonを使ってSpotifyAPIを操作して作ったものの話を予定しています。サークル名は「サポーターズCoLab」です。

1人でも多くの方に手に取ってもらえるような内容に出来るように頑張ります。

 

YouTube music がリリースされたので、使ってみる

昨日より、日本でもYouTube musicが使用可能となったので、使ってみました。

 

music.youtube.com

 

私個人は既にGoogle Play Musicの有料版を使っていたので、追加課金なしで使用可能でした。

 

YouTubeが関わっているので、Google Play Musicよりパワーアップしたような気がします。

さて、個人的にはこのYouTube Musicを心待ちにしていました。というのも、Google Play Musicには公式APIはありませんが、YouTubeにはAPIが存在するからです。現段階でYouTube Musicに特化したAPIはありませんが、今後リリースされた場合には再び音楽系のモジュール作りをしたいと思います。

自分に合った技術記事の探し方を考える

またも、久しぶりの更新になってしまいましたが、今日は自分に合った技術記事の探し方について触れたいと思います。

 

自分では自宅・業務問わずGoogle検索にて様々な技術記事に目を通します。ただ、時間の関係上どうしても上位の検索結果に出てくる記事に流れてしまいます。先日、某プログラミングスクールのC言語に関する記事が技術的に間違っていると話題になりました。こちらのブログ記事はGoogle検索には毎回上位に出てきています。しかし、C言語での一件から自分に取っては例のプログラミングの記事が「ノイズ」となってしまいました。よって、現在はドメインを「マイナス検索」して省くようにしていますが、今後ドメインが増えると対処しにくくなります。

 

また、会社ではSlack botが技術記事を自動で持ってくる運用がされていますが、ピンポイントで疑問がある場合にはどうしても検索エンジンを使ってしまいます。

 

検索結果の上位に出そうとするSEO対策を否定するつもりはありません。それは、記事は見て貰わなければ意味が無いので見て貰うための1つの方法だからです。しかし、人によってはSEOによる結果をノイズと感じてしまう場合もあるので、例えば「悪いね」ボタンを検索結果の横に置き、ノイズを手軽に除去出来る仕組みがあればと思います。

 

もし、こういう形で技術記事を集めているという事を教えて下さる方はコメント頂けるとありがたいです。

「エンジニアブログを一年続ける方法」に参加してきました

ちょっと間が空いてしまいましたが、10月3日に「エンジニアブログを一年続ける方法」に参加しました。

 

supporterzcolab.com

 

発表者は以下のブログ主です。

 

willow710kut.hatenablog.com

 

ブログを続けるにあたって、一番大事なのは「無理しない」というのは共感しました。無理しすぎて、力尽きてしまうのは意味が無いので、細くても続けるのが大事なのは改めて感じました。

 

ただ、業務に関するコードは全てGithubのプライベートリポジトリ内なのであんまり書けない気がするので、やっぱりプライベート開発に終始してしまうかもしれないですね。

 

(以上の記事は会場で記入しました。)