nukorouのゆるガバ帳

ゆるくガバく適当に

法人インフォメーションAPIをRubyで取得する

はじめに

久しぶりの更新になってしまいました。

昨日(2017年1月19日)、法人インフォメーション(略称:法人インフォ)が公開されたので、Rubyで取得するところまでやってみたいと思います。

準備

このAPISPARQL(スパークル)というRDFのクエリ言語でクエリを書くみたいです。ちなみにRDFもSPARQLも初めて扱います。(SQLはSELECTとFROMぐらしかわかってません。)

gem install linkeddata

RDFを扱うためのモジュールをまとめてインストールしてくれるそうです。

コード

ざっくり説明しますと、get_all_hojin_id関数で法人番号(ID)を取得して、get_hojin_base_info関数にIDを渡しています。

SPARQLでは、?変数名が変数になるようです。

情報てんこもりのget_hojin_base_info関数は最初は理解しにくいかと思ったので、最小構成のSPARQLの例示として、get_name関数も用意しました。

あと、get_all_hojin_id関数では実は全部のIDは取得できません。SQLが分かる人には当たり前なのかもしれませんが、OFFSETが必要です。あえて、把握しにくくになるからOFFSETは書かなかったのですが、別に問題ないですよね。

あと、地味にOPTIONALってのは重要です!これがないと、全部の情報が必須の条件になってしまうため、ヒットしません。これは、必須ではないよって明示しているのが、OPTIONALみたいです。ここでつまりました。

require 'sparql/client'

def get_all_hojin_id(client=nil, limit)
  if client.nil?
    client = SPARQL::Client.new('http://api.hojin-info.go.jp/sparql')
  end
  query_string = "
    PREFIX hj: <http://hojin-info.go.jp/ns/domain/biz/1#>
    PREFIX ic: <http://imi.go.jp/ns/core/rdf#>

    SELECT ?id FROM <http://hojin-info.go.jp/graph/hojin>
    WHERE {
      ?s hj:法人基本情報 ?key .
      ?key ic:ID/ic:識別値 ?id .
    }
    limit #{limit}
  "
  results = client.query(query_string)
end


def get_name(client=nil, id)
  if client.nil?
    client = SPARQL::Client.new('http://api.hojin-info.go.jp/sparql')
  end

  q1 = "
    PREFIX hj: <http://hojin-info.go.jp/ns/domain/biz/1#>
    PREFIX ic: <http://imi.go.jp/ns/core/rdf#>

    SELECT ?name FROM <http://hojin-info.go.jp/graph/hojin>
    WHERE {
      ?s hj:法人基本情報 ?key .
      ?key ic:ID/ic:識別値 '#{id}' .
      ?key ic:名称/ic:表記 ?name
    }
  "
  results = client.query(q1)

end

#個人的に必要そうな情報しか取得してません
def get_hojin_base_info(client=nil, id)
  if client.nil?
    client = SPARQL::Client.new('http://api.hojin-info.go.jp/sparql')
  end

  query_string = "
    PREFIX hj: <http://hojin-info.go.jp/ns/domain/biz/1#>
    PREFIX ic: <http://imi.go.jp/ns/core/rdf#>

    SELECT DISTINCT * FROM <http://hojin-info.go.jp/graph/hojin>
    WHERE {
      ?s hj:法人基本情報 ?key .
      ?key ic:ID/ic:識別値 '#{id}' .
      ?key ic:ID/ic:識別値 ?id .
      OPTIONAL{?key ic:名称/ic:表記 ?name .}
      OPTIONAL{?key ic:住所/ic:表記 ?address .}
      OPTIONAL{?key ic:住所/ic:郵便番号 ?zip_code .}
      OPTIONAL{?key ic:住所/ic:都道府県 ?prefecture .}
      OPTIONAL{?key ic:住所/ic:市区町村 ?city .}
      OPTIONAL{?key ic:住所/hj:丁目番地等 ?chome .}
      OPTIONAL{?key ic:活動状況/ic:発生日 ?start_day .}
      OPTIONAL{?key hj:更新日時/ic:標準型日時 ?updated_at .}
    }
  "
  results = client.query(query_string)
end

if __FILE__ == $0
  client = SPARQL::Client.new('http://api.hojin-info.go.jp/sparql')
  ids = get_all_hojin_id(client, limit=10)

  ids.each do |i|
    name = get_name(client, i.id.to_s)[0].to_h[:name].to_s
    puts name

    base_info = get_hojin_base_info(client, i.id.to_s)[0].to_h
    puts "id:#{base_info[:id]} name:#{base_info[:name]} address:#{base_info[:address]}\n\n"
  end
end

改良するなら

公式PDFの、追加したいデータ名のプロパティパスっていうカラムをコピペして、変数名を自分でつけたらいいと思います。って誰でもわかるかw

参考

hanzomemo: DBpedia日本語版:SPARQLをRubyから実行

RDF.rbを用いたRDFデータの読み込み - Qiita

【第1話】フロントエンド修行物語【WebpackとRiot.js準備編】

まえがき

これは刹那を作る修行物語の第1話です。 前回の記事はこちらです。 nukorou.hatenablog.com

前回、フロントのデザイン作るとか言ったけど、あれは嘘だ。デザインだけを作る*1の面倒すぎたから、今回は機能作りながらデザインも適用していくことにした。

俺がアホ過ぎるんかもしれんけど、Webpackを理解するのにめっちゃ時間かかった。わかると便利。

こんなクソ雑魚ブログを見てくれてる人はかなり少ない*2とは思うが、普段サーバサイドばっかりでフロント全然知らんって人は境遇的に参考になるかもしれない。ただ、よくあるありがたいチュートリアル記事ではないので注意。

*1:普段は、デザインだけBootstrap studioってソフトでデザインだけ先に作って後で合体させるという手法を使ってます。

*2:いない

続きを読む

【第0話】フロントエンド修行物語【導入編】

まえがき

Qiitaに面白い記事がないかと徘徊してたら、クソアプリ Advent Calendarなるものを見つけた。

個人的にとりあえずアウトプットする人は尊敬している。皆さん、良い物作ってらっしゃる。

中でも気になったのが14日目の結局アレはどうなった? 「はきだめ」もとい「Setsuna」プロジェクトだった。

「投稿に寿命のついた匿名掲示板」

仕様

  • 投稿します
  • 通常6時間後にDBからも抹消されます。魚拓でも取らない限り残らない。
  • しかしレスポンス(「共感ボタン」を押される、返信される)が来ると記事の寿命が1時間伸びる
  • パスワードを控えておけば、手動で消せる

こんなものらしい。なんかそんなSNSあったよな〜と思ってGoogle先生で「sns 消える」と調べたらSnapchatやらSNOWやらが出てきた。これらはメインが写真だけど、Setsunaはメッセージがメインなのね。なるほど。エフェメラSNSというらしい。

これ系はいっとき流行ったみたいで、クローンがいろいろ作られたみたいだがそんなことは正直どうでもいい。

消えるのにつぶやく意味がよくわからなかったので、どんなことがつぶやかれるのか見たかったのだが、残念ながら Setsunaは未完成 らしい。記事によると

多分、できてる。サーバーサイドだけ。

ということらしい。私は最近フロントの技術に興味を持ち始めた にわかサーバサイドエンジニアなので、勉強のためにもフロントを実装する(できるとはいってない)のはいいことのように思えた。それに、永遠にサーバサイドだけしか書かないってのもおかしな話である。勉強しといて損はないはず。

それに教材としてかなり都合よく

お暇な人はコードをcloneしてサービス立ち上げてしまって構いませんぜ。

とのことなので、ステップアップのためにもフロントを勝手に完成させてしまおう。なんせ、学生なもんで社会人と比べれば時間はある。

で、herokuにデプロイすんぞ〜となった訳です。

続きを読む

Electronで天気アプリ作ってみた

このエントリーはElectron Advent Calendar 2016 - Qiitaの8日目です。

tenki.jpの天気をメニューバーのアイコンでわかりやすく

そら案内

そら案内

  • sorakaze Inc.
  • 天気
  • ¥360

そら案内が有料で少々驚いた。まぁ、高機能だし多少はね?

ただ、簡単に今日、明日の天気の気温と降水確率がわかればいいのに、お金だしたくない。(てか、作れそう)

作ろう!

技術選定

  1. 気軽に

  2. 流行ってそうなやつ

  3. 今後も使えそうなやつ

こんなガバガバ選定で、Electronええやんってなった訳です。

こんなやつ作りました

f:id:nukorou:20161207235840p:plain

アイコンをクリックで天気が見れて、右クリックでメニューがでます。

処理の流れ

  1. 起動

  2. tenki.jpを1時間毎にスクレイピング

  3. 表示

というシンプル設計です。 普段、JSとか書いてなくて、最近フロントの技術いいなぁと思い始めた感じなので、めっちゃコードが汚いです。(言い訳

特に$($(~~~~~))みたいなところがあって、「これ絶対もっときれいにかけるやん」と思いながらも、期限は刻々と迫ってきたのでこの辺で切り上げました。

イケてるところ

ない

無料

オープンソース(誰かが良くしてくれるかもw)

イケてないところ

Electronの癖にMacしか動作を確かめてない

他のOSでも動くのだろうか?

URLは自分で設定してビルドするという糞仕様

現在は適当に東京の方を選んでおいたので、もし使って見たい方がおられましたら自分の地域に設定してビルドしてください。(これも、本来であれば郵便番号とかで一発で出せるようにしたかったんですがタイムオーバーです)

見た目

CSSとか書いたことないレベルなんで大目に見てください(泣)

自動起動設定がない

電源落としたら手動で起動しないといけません。

たまにバグる

エラー処理とかほぼしてないので、なんかの拍子に「//Infinity」とかなります。 再起動して下さい。

まとめ

普段、Rails書いてる人でもなんとなくでデスクトップアプリが作れました。どんどん、便利なツールを作りたいと思います。

あと、時間管理はしっかり。。。

あと、バグ報告や、プルリク大歓迎です。 気軽に、日本語でいいのでお願いします。

github.com

WebStormを使ってElectronのレンダラープロセスをデバッグする方法

Getting started with Electron in WebStorm | WebStorm公式ブログ丸パクリした参考にした。

手順

electron起動の設定をいじる

エディターの右上から f:id:nukorou:20161203124117p:plainf:id:nukorou:20161203124114p:plain

electronを選ぶ。設定してない人はEdit Configurationsを選ぶ。

f:id:nukorou:20161203124115p:plain

Application parameterに--remote-debugging-port=9222を設定する。ポートはお好きに設定してください。

f:id:nukorou:20161203123929p:plain

Chromium Remoteの設定をする

f:id:nukorou:20161203124118p:plain

エディター右上からEdit Configuration→Chromium Remoteを選ぶ。 さっき設定したポートと同じのが書かれているかをみる。上で9222やった人は何もしなくて大丈夫なはず。

f:id:nukorou:20161203124110p:plain

デバッグモードで起動する

ElectronのメインプロセスもデバッグしたければElectronもデバッグモードで起動する。起動したらChromium Remoteをデバッグモードで起動する。ここでもし、Electronのアプリに開発者ツールがでてるのなら消しておかないと怒られる。あとは、ブレークポイント貼って止まるか確認して終了。

お疲れ様でした。

seleniumでbasic認証がかかってるページに入る

basic認証についてよくわかってなかったけど、普通に<user>:<pass>@hoge.comで行けるのね。

ちなみにRubyバインディングで使っているので

driver.get '<user>:<pass>@hoge.com'

こうなりました。

参考記事

HTTP Basic Auth and Proxy for selenium-webdriver (ruby bindings) | stackoverflow

プログラミングを学び始めて3年ぐらい経ったので遍歴まとめてみた

自分の肩書き

まぁ、お前誰だよって話で、最初のエントリーだし一応簡単に経歴等を紹介しておく。

関西の大学四回生で、24歳学生ではない。情報系の大学に通っている。

就職先は既に決まっている。Web系(が強い)の会社だと思う。

クソザコエンジニアです。

プログラミング言語遍歴

だいたいこんな順番で勉強したというか書いたと思う。 ここでリストにあげているのは、別にマスターしたというわけではない。ただ書いたことがあるという基準である。

C

こいつは一回の時に(東京では1年っていうんかな)大学の講義で学んだ。型という概念やプログラミングの基礎を学ぶのにはいいのかもしれないが、味気なさ過ぎ。コンソールに出力される文字列を見て何が楽しいねん!(白目)。楽しさについては教えてくれなかったあまりいい思い出のない言語。

  *
 ***
*****

こういうピラミッドをforの2重ループで作るやつで最初につまづいて、「ああ、俺は絶対にエンジニアにはなれない」と強く確信したのを今でも覚えている。エンジニアに憧れて情報系の大学に入ったのだが、少し挫折した。(そこからあるときまではプログラミングを嫌いになった。)

まだ、プログラマ(ここでは、給料を貰ってコードを書く人と定義)になった訳ではないが、結論から言うとその確信は大きな間違いだった。

Java

二回の時の実習で学んだ。こいつはクラスの概念を教えてくれた。構造体より、断然便利だな〜と当時思ってたような気がする。

Processing

二回の時に独学で勉強した。 厳密には言語ではない気がする。

電子アートとビジュアルデザインのためのプログラミング言語であり、統合開発環境である。Processing - Wikipedia

先生によると言語らしい。俺は、Javaラッパーという位置付けだと思っていた。

そんなことはともあれ、こいつは神すぎた。アニメーションとか、動くものが簡単に作れる。ライブラリも簡単に導入できて、見えるものがこんなに簡単に作れるのは俺にとっての革命だった。ゲームとかも作れると思うし楽しかった。こいつが、プログラミングの楽しさを教えてくれたと言っても過言ではない。前述のプログラミング嫌いが解消された。

Python

三回の時に勉強した気がする。独学。 こいつは更に神だった。最初は、「なんだこの気持ち悪いインデントのブロックは」なんて思っていた。よく言われるかもしれないけど、これは慣れると止められない。型がないのは新鮮だった。あと、pip(ライブラリのインストールツール)が便利すぎて驚いた。

三回の時に就活で出会った人の影響で、Webアプリにはまる。PythonでWebアプリ作るなら個人的に、BottleJinja2を使って作ればいいと思う。めっちゃわかりやすいし、大規模なプロジェクトとかじゃなけりゃ普通に使えるはず。

Ruby

三回の時にWebアプリはまった時に勉強始めた。独学。2度挫折した。 Ruby on Railsを学ぶために始めたがこれは間違いだった。 Ruby自体を学ぶことに問題はなかったのだが、Webアプリケーション全部入りのRailsを最初に(PythonとBottleを勉強する前に)勉強しようとしたのは間違いだった。覚えること多すぎて死んだ。「MVCが何ぞや」ってちゃんとわかる前にやるような代物ではないのではないかと思う。

Rails(挫折) -> Bottle -> Rails(挫折) -> Bottle -> Rails ぐらいでやっと理解できたような気がする。

まあ、別にBottleである必要は全くないので、Rubyで言うところのSinatraあたりを最初に勉強するのがRailsを理解するための早道な気がする。

C#

Unityで遊びたかったから、ちょっとかじった程度。

JSとHTML

こいつらは、必然的にWebアプリケーションを学ぶ時に書く羽目になったので、その都度リファレンスというか見ながら書いてたイメージ。

個人的にお勧めな勉強順

もちろん異論は認めるが、プログラミングが嫌いにならない程度にCやってPythonとか緩い楽しい言語やればええんじゃないかな〜って思う。逆の順だと型とかなんやねんってなりそうで辛そう。もちろん正解なんてないと思うし、好きな言語なんて人それぞれだと思う。

大事なのは、用途に合わせて技術選定することかなって思う。言語なんてあくまで、ゴールに到達するための手段でしかない。どんだけその言語が好きだったとしても、やはり得意分野不得意分野あるので、作りたいものに合わせるしかない。

極論

ある程度プログラミングの流れがわかれば、どんな言語でもリファレンス片手に書けるようになる。大事なのは、ロジックとかアルゴリズムの方。

ただし、楽しく書けるかは別である。