2018年3月26日月曜日

code-prettifyで技術ブログの可読性アップ

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

今回はちょっと臨時番外編をお送ります。

サイトが見辛い

最近はQiitaという技術交流SNSが注目を集めていますよね。
私も技術調査を行っている時にQiitaに掲載されている記事にお世話になることが多いです。

それを見ていて思うのが、何かこのブログって掲載しているブログが見辛いなぁ。。。




このブログを始めた2013年当時、私はGoogleが提供してくれているコード掲載用ライブラリである「code-prettify」を導入したのですが、
今となっては明らかにQiitaとか他の技術ブログより見辛いぞ。

一体どうなってんの???

と言うことで、現状に甘んずることなく、ブログの品質向上を目指して見直しを行うことにしました。

何か良いライブラリ無いかな。。。

code-prettifyだった

そして調査して分かりましたが、私のやりたいことは「code-prettify」で出来るんですね。

code-prettify自身が2013年当時から進化していて、最新版を持って来れば良いんですよ。

2013年の頃はGoogle本家に置いてあったと記憶しているcode-prettifyも、今はGitHubに引っ越ししているようです。


今まで使っているcode-prettifyを消して、新しいのを入れなおしてみましょう。

run_prettify

run_prettifyはAjaxライブラリの一種なので、HTMLのヘッダーで宣言が必要です。

以下のようにCDN(コンテンツデリバリネットワーク)の以下を宣言して下さい。

<script src="https://cdn.rawgit.com/google/code-prettify/master/loader/run_prettify.js"></script>


CDN……。
要するに、Googleの親サイトに直接繋いでJSファイルを読み込むわけです。

便利である一方、Googleのサイトが落ちたり、無くなっちゃったりすると死んでしまうわけですが、run_prettifyはCDNを使った方が良いと思います。

容易な変更が許されない業務システムで使うライブラリであれば、そのシステムをリリースした時のバージョンを維持する為にJSファイルをローカルにダウンロードしてシステム内部で保持する必要があります。
でも、このブログって業務システムではないですし、何より新しさが重要ですから。

CDNが無くなったり、引っ越ししたりしたら、それに合わせてブログを更新するべきだと思います。
更新が遅い技術ブログなんて役に立たないっしょ?

何年も前に取得した古いライブラリを維持するとかは業務系システムで考えるべきことで、こういうブログは目新しさを求めてCDNを呼べば良いと思います。

さて、「run_prettify.js」ですが、これで描画に必要なスタイルシートとかも全部読み込んでくれています。

ですが、読み込む際にオプションを指定することが出来ます。




いくつかありますが、気になった所を挙げてみましょう。


  • autorun:自動実行。画面のonLoad時に自動実行することで、デフォルトはtrueです。どうも昔は自動実行が無くて、自分でonLoad実行しなきゃいけなかったようですが、今はこのとおり、自動実行でラクチンです。
  • lang:プログラミング言語の指定。code-prettifyは「Java表示モード」「Python表示モード」みたいに、言語毎にグラフィックを変えてくれるというIDEみたいな凄い技をやってくれます。そのデフォルト言語ですね。デフォルト言語をPythonにしておけば、何もしなければPythonモードで表示され、その上でJavaにしたい時はHTMLの中のclassにJavaを指定すればそこだけJavaモードになります。
  • skin:スキンの指定。後述。

大事なのは「skin」かな。




上記のページにあるスキンからお好みのものを選ぶことは出来ます。
当ブログは長らくdefaltでしたが、今回を期に「Sons-Of-Obsidian」に変更します。



<script src="https://cdn.rawgit.com/google/code-prettify/master/loader/run_prettify.js?skin=sons-of-obsidian"></script>



これで宣言完了。

書く

ここから先の使い方は簡単です。
例えばPythonのコードを載せたい時は、以下のようにHTMLを書けばOK。

<pre class="prettyprint linenums"><code class="language-python">...コード...</code></pre>

「linenums」とは行数を表示するオプションです。
特に理由が無い限りは常につけておいた方が良いでしょう。

実際、このやり方で上記の画像の状況だったソースを掲載すると以下になります。


import os
import json

dirPath = 'C:/MyMail_result'
files = os.listdir(dirPath)

#連想配列を作成
map = {}

#ファイルを全部読み込み
for file in files:
    f = open(os.path.join(dirPath,file))
    data = json.load(f)
    f.close()

    #name毎にsalienceを集計
    for entity in data['entities']:

        name = entity['name']

        if name in map:
            map[name] = map[name] + entity['salience']

        else:

            map[name] = entity['salience']

#集計結果をソート
resultList = reversed(sorted(map.items(), key=lambda x:x[1]))

#出力
for data in resultList:
    print(data[0] + '\t' + str(data[1]))

これこれ。
これをやりたかったんですよ。

今の時代なら絶対コレしか無い!!

終わりに

よっしゃ。これで綺麗になったぞ。
やっぱね、5年も同じブログを続けていると時代遅れになっている部分があったとしても、どうしても「これでいいや」って気分になりがちなんですよね。
今までそれでやって来ているわけですから。

でも、偶にで良いので振り返って、「いやいや、今ならもっと良いやり方があるぞ」という所を見つけたら、改善を決行しなければなりません。

「今までそれでやって来た」というだけで改善を行わないという怠慢!!

ブログ運営に限らず、業務を行う上では常に気を付けていきたいものです。

2018年3月19日月曜日

Pythonで社内システムを作ってみた~序章~

株式会社ジェニシス 技術開発事業部の遠藤 太志郎(Tacy)です。

先週まで勉強を兼ねて、PythonとGoogleの機械学習API「CLOUD NATURAL LANGUAGE API」の連載を行っていましたが、
おかげ様で何とか感触を掴めてきました。

しかし「勉強の為の勉強」だと、どうもピントがぼやけた調査になってしまうのが現実のところ。
そこで「社内システムの開発」を想定して、ちょっくらPythonで社内で使えそうなシステムを作ってみようと考えるに至り、ようやくある程度の形になってきたところです。

そこで、今回より新シリーズ「Pythonで社内システムを作ってみた」を始めていきたいと思います。

着想

テーマとして選んだのはSEならみんなお馴染みの、「業務経歴書」です。

弊社の業務経歴書はIT界で悪名高い神エクセルの類です。

エクエルに各自書き込むという方式なので記述粒度が人によって合ってなかったり、印刷してみると微妙に見切れちゃってたり、
とか細々とした問題が多いという感覚が現場の実感としてありました。

私の業務経歴書はこんな感じ。(ちょっとだけお見せします)



一見すると綺麗ですが、これがエクセルで、実は問題もあるんですよ。

デザインの改善点の指摘もあるのですが、何せ全員が各自個別にエクセルファイルを持っている形ですから、
デザイン変更したくても全員が同じようにレイアウト変更作業をやるのは大変だから二の足を踏んだりとか、
やっぱり「個別管理」「エクセル形式」というのは、手っ取り早いのは良いですけど長期的管理体制には不向き。

そこで私は「これをWebシステム化して一元管理したら業務改善になるんじゃないかな?」と考えるに至ったわけです。

課題

「Webシステム化する」と言うだけなら簡単ですが、それをソリューションとしてビルドアップするのは中々ハードルが高いです。
開発進行過程で課題になった点をご紹介しましょう。

言語はPython

これは課題と言うより「前提」ですが、言語は最初からPythonにしようと思っていました。
そもそもはPythonの勉強から始まっている、というのも大きいですが、もう一つの理由としては「優遇」があります。

プログラミング視点では「小規模Webシステムなんてどんな言語使っても対して変わらん」というのが実際のところですが、環境面だと意外にそうでもないです。

過去の連載で私はGoogleAppEngineを使用し、ネタバレになりますが今回はAWSを使用しましたが、その所感としてPythonはクラウド界で優遇されています。

クラウドサービスは言語を指定されている製品がありまして、「この製品はPythonは使えるけでRubyは未対応」など、クラウド製品の都合で言語が縛られるケースがあります。
そんな中、Pythonは常に対応していました。

  • とりあえずPythonならばクラウドはOK

私は寄らば大樹の陰という主義のエンジニアですが、Pythonは寄って安心の大樹だと思います。

基盤

基盤は「クラウド+サーバレス(従量課金制)」しか無いと最初から思っていました。

この業務経歴書管理システムは、その性質上、業務経歴が書き換わるタイミングしか出番が来ないものです。
個人単位だと数ヶ月~数年に一度しか使いません。

そんなシステムの為にサーバを常駐させておくなんてのはコスト的にあり得なくて、システムを使うときだけ費用が発生する従量課金制のクラウド・サーバレスサービスしか無いというのは自明の理でした。

サーバレスサービスは、やはり以前に連載していたGoogleAppEngineが業界代表格でしょう。
この連載の中で別のシステムを作っていましたから、「サーバレスとはどういうものか?」「どういう時に出番が来るのか?」という知見はありました。

今回は同じサーバレスでも別製品、AWSのサーバレスを使うことにしました。
GoogleではなくAWSにした理由は、弊社の方針ですね。
今後、弊社ではAWSに力を入れていこうという方針があるので、そこに乗っかることにしました。

特にAWSの方がGoogleより向いている何かがあったわけではありません。
しかし、あっちこっちの技術に手を伸ばしていると片手落ちになってしまうので、合わせられる部分は合わせよう、とAWSにすることにしました。

Webシステム・フレームワーク

「PythonでWebシステムを作るとしたら、フレームワークはどうしよう?」と思いました。
調べてみると「django(ジャンゴ)」というフレームワークが見つかったのでコレにしました。

と言うか、PythonのWebシステム界ではdjangoが支配的地位です。
django以外の選択肢なんかありません。


帳票出力

最大の問題点。
業務経歴書は印刷して面談に持って行くという紙媒体が運用上絶対に外せない要件です。

  • Webだけなら誰でも出来る。
  • 印刷はどうすりゃいいんだ!?

帳票出力は技術的最大のハードルです。

  • Yahooの時刻表印刷みたいにWeb画面を印刷する。
  • 現在と同じくExcelを出力する。
  • PDFで出力する。

色々考えて検証しましたが、これらにはそれぞれ問題点があって解消出来ませんでした。

  • Web画面印刷⇒ブラウザ依存でどうしても微妙に見栄えが変わってしまう。
  • Excel印刷⇒印刷時の見切れに対応出来ない。
  • PDF⇒柔軟性が無さ過ぎる。例えば営業が「ちょっと急ぎ手直ししたい」という状況が発生した時に書き換えられない。

これらを踏まえて、最終的に「Wordで出力する」という仕様に結論付けました。

Word出力もこれはこれで難しくて。。。
最初はPythonでやろうとしましたが、どうしても実現不可能なケースがあったので、Pythonは諦めてココだけJavaでやることにしました。

Word出力の奮闘記は後の連載でご紹介します。


システム構成

そんなこんなで試行錯誤した結果、以下のようなシステム構成図でまとまりました。



大きく「Webシステム」と「帳票出力API」に二分割されています。

終わりに

今後はシステム構築に至るまでの過程やノウハウの連載を始めていきたいと思います。


  • Webシステム実装:Python&Django編
  • Webシステムインフラ:AWS Elastic Beanstalk編
  • 帳票出力API実装:Apache POI編
  • 帳票出力APIインフラ:AWS Lambda編


システム全体としては色々と詰め込まれていますが、それぞれ非常に疎結合となっています。

「ベンダーロックオン」と言いまして、クラウドの話をすると以後ずっとそのクラウドから抜け出せなくなることを気にされるケースがありますが、作ってみたところ、別にそんなことは無さそうでした。

ログ出力の設定とか多少のことはありますが、「作ったアプリのインフラを別のところに引っ越したいんだけど?」となった場合でも、特に問題にはならない規模です。

従って、連載を進めていく上で「インフラ編を読んだ後じゃないと実装編の意味が分からない」とかにもならないと思います。

連載は、システム規模が


  • Webシステム>>>帳票出力API


なので、まずは手短な帳票出力API編から始めていきたいと思います。