.この薄っぺらいブログが見えるというのか/

自転車・PC・読書感想。サイクリング部の大学生やってます。

新歓をスムーズにしようとしたらめんどくさかった話

最近大学で新歓をしていて、僕は割と熱心に部活をやってるし、特別嫌でもないので新歓代表をしている。

新歓をする際に気をつけていることは2つあって、1つ目がとにかく新入生がわかりやすい情報を提供すること。2つ目が、使えるツールは使って自分たちの負担を減らすこと。

1つ目に関してだがまず情報の提供元を一元化することに努めた。僕の所属しているサイクリング部は競技志向のグループとツーリング志向のグループと、というように内部でいくつかに分かれていて、それぞれが勝手に行動するので行動が統一されていなかった。あるところではtwitterとブログ(excite)、もう一つのところではtwitterとHP(20年前に先輩が自作したもの)、他のところはまた違う。というようにとにかくバラバラだった。1つの部活の中に複数の部活があるようなものだ。

僕はこれをはてなブログtwitterに一元化することを提案した。

はてブロを選んだのにはいくつか理由がある。

はてブロなら1つのアカウントで複数のブログを持てる。それぞれのブログを活動内容に応じて割り当てれば良い。理想を言えばサイクリング部全体でメインドメインをとってサブドメインを使って階層化できれば最善だがそれは出来ないし、まぁ今までに比べればだいぶマシだろうということで妥協した。

それととても大事なのがブログメンバーを設定できることだ。ブログメンバーを使えばアカウントを使いまわす必要はなくなり、将来パスワードを忘れたからログイン出来ないということが起こらない。僕が今までの運用に最も不満を感じていたのはこの点だったからこれが解消できるのは大きい。proで最も注目されないであろうブログメンバー機能だが、僕はこれを実装してくれたはてなに心から感謝したい。

はてなブログは開発が活発で、使用者も多いからわからないことがあれば検索すればすぐに見つかる。デザインを変更したければ管理者の権限を与えてもらって、ドラッグ&ドロップでおしまいだ。テーマを変えれば全体の雰囲気を変えられるし、不満であれば自分で作ることもできる(知識は要るが)。

メリットしかなく、即承認されると思われたこの案だが、意外なことに結構な時間がかかった*1

曰く「OB, OGが前のデザインの方が好きかも」「proが有料なのが気になる」「めんどくさくない?」などなど。積極的な反対意見ではないが、かといって賛成意見では絶対にありえない。思いついただけのような意見だろうけれど、このような意見が第一声としてでてくるのには驚いた。先に述べたような数々のメリットを差し置いて出てくるのがそれか。幸い、ある先輩がバックアップしてくれたし、他の部員も説明すればわかってくれたので、多少強引にすすめることで移行を完了させた。

次に取り組んだのが新歓用の公式LINEアカウントを用意することだ。大学の新歓といえば新入生用のグループを作って、新入生を片っ端からぶち込んでいくのが普通だ。

僕はこれが嫌だった。まず友達欄が汚れる。ミニマリストのように最小に保ちたいわけではないが、新歓で100人も連絡をとらない友達が増えるのは勘弁してほしい。さらに言えばQRを読み込んで、「〇〇くん?新歓グループに入れておくね」の定型句とともにグループへ招待などという非効率極まりないことをしたくなかった。こうやって無理やり招待した新入生の大体が招待を放置するのだから徒労感も増える。

そもそも新入生を招待するために「新歓グルはこれです!」といって新歓に携わる人を1人ずつちまちま招待するのも嫌だ。連絡が不徹底だとグループが複数生まれることもある。

だから僕は公式LINEを作った。これならQRを読み込んでもらえばおしまい。うざいならブロックでおわり。誰の友達欄が汚れるわけでもないし、単純に考えて手間数が圧倒的に少ない。

ただこれも新歓当日になって反対意見が噴出した。ビラに公式LINEのQRコードを載せ、それをLINEグループに流し、反対意見がないから承認されたものと認識していたのが駄目だった。みんなはただ見ていないだけだったのだ。

これには面食らった。主にあった不満は、個別にチャットできないじゃんというもので、これは(意見がでた時点では)そのとおりだ。その後、(仕様のため)"向こうからLINEが来たときのみ"個別チャットが開始できるように設定した。ただこれにも不満も持つ人も少数いた。

その他の意見も確かあったはずだがよく思い出せない。確かにと思う意見もあれば、いちゃもんかよと思うものまであった。ただそれは事前に言っておいてほしかった。まぁこれは僕が「反対意見がないなら賛成かな」と高をくくって説明を怠ったのも原因としては大きい。

他にも、サイクリング部全体LINEが無いため、僕が毎回4つぐらいのグループに新歓予定を送っていたので、全体LINEを作ろうとしたらこれまた文句を言われたり。LINEに子グループを作る機能があれば理想的だった。slackにならこういう機能があるのかも知れないが、あいにく大学生が一般的に使うようなSNSではない。

僕はサイクリングが好きだから他にもやりたいことはいっぱいある。会計の透明化、口座の一元化(今は分かれている)、放置されているゴミの整理、乱立する役職の削減と仕事内容の明確化、できればブログのコンテンツ化&収益化などなど絶対にメリットになることだと僕は確信しているが、新歓だけでこれだけ面倒くさいとなると正直ためらってしまう。

*1:exciteブログにエクスポート機能がない、自作HPからスクレイピングしないといけないなどの問題もあったが、それは置いておく

django で自分で作ったファイルをダウンロードさせる

どういうときの話?

例えばユーザーの入力によって動的にファイルを作り、そのファイルをModelのデータベースに保存1させつつ、ユーザーにダウンロードさせたいとき

下準備

# @settings.py
MEDIA_ROOT = os.path.join(BASE_DIR, 'media/')
MEDIA_URL = '/media/'

参考

設定 | Django documentation | Django

Djangoで、ファイルダウンロード | NARITO BLOG

スラッシュの過不足があったりするとエラーが出るので注意。

# @urls.py
from django.conf import settings
from django.conf.urls.static import static

urlpatterns = [
    # ... the rest of your URLconf goes here ...
] + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

これはユーザーだけじゃなくて、自分でアップロードする場合にも必要。これは開発時の設定なので注意

参考

静的ファイル (画像、JavaScript、CSS など) を管理する | Django documentation | Django

# @models.py
from django.db import models

class FileModel(models.Model):
    file = models.FileField(upload_to='files/')

足りない所は想像力で補ってください。

ファイルをModelに保存する

from django.core.files.base import ContentFile
from .models import FileModel

string = 'this is sample file content'
myfile = FileModel()
content = ContentFile(string)
myfile.file.save('file_name', content)

参考

モデルフィールドリファレンス | Django documentation | Django

こうするとDBに登録されるのでフィルターとかソートとかして取り出せる(はず)。

同名のファイル名で上書きすると、suffixが付いたファイルが新たに作成されて、そちらがDBの指すファイルの実体となる。もとのファイルが削除されるわけではない。

html側は、

<a href="{{ uploadfile.file.url }}" download="{{ uploadfile.file.name }}">{{ uploadfile }}</a>

のようにdwonload属性を使うのが手軽でいいと思う。

参考 

Djangoで、ファイルダウンロード | NARITO BLOG


  1. この言い方は正しくないが

俺的python初学者学習フロー

これはなに?

python流行ってる。俺もdeep learningにつられてpython触った。ついでにいうとそれがきっかけで大学も決めた。で、初心者がpython触っても文法覚えるトコまでは行けるけどその後がどうにも繋がんないと思う。このあと何やったらいいんだろう・・・ってなる。そんな人に向けて書く俺的指針。 ただここに書く流れは今振り返って理想的だと思う流れを書いたのであって、別に他の分野やってフラフラしてもいいと思う。結局下に書く知識は必要になるので、そういう経験してモチベあげるとかも全然あり。というか俺がそうだった。

あなたは誰?

情報系の学部一年生。まぁ俺も初心者で全然業務で使ってるとかじゃないんで、「新入社員100人を教えてわかったpythonの学習法!」とかそんな大したもんじゃなくて、つまりはこの記事に特に信憑性はない。ちなみに1つだけpythonのパッケージ作りました。使ってやってください・・・ github.com

はじめの一歩

とりあえず入門書を買ってやりきれ。間違っても 分厚い蛇の本買ってはいけない。俺はこれで勉強したけどまぁ人気あるのならなんでも良いんじゃないかな。とりあえず文法を知らないことには話にならない。

文法を覚えたらLinuxをやれ

ここで残念なお知らせなんだけど、pythonを覚えただけじゃpythonで開発できるようにはならない。 「Web系に興味があるからDjangoでもやってみようかな〜〜」とかほざいてる君。1000000%ドキュメント読めないので諦めよう。俺がそうだった。

次に進むためにはlinuxを使えるようになろう。「おれはpythonがやりたいんであってlinuxじゃない!」「pythonの上にlinuxは無理」などなど言いたいことは沢山あるのはわかる。でもしょうがないじゃないか。こればっかりはどうしようもない。だって大体のpythonのドキュメントがlinux前提で書かれているんだもの。

たとえばこれ読めるか?

Python インタプリタは、それが使えるマシン上では通常 /usr/local/bin/python3.7 としてインストールされています; Unix シェルの検索パスに /usr/local/bin を入れることによって、次のコマンドをタイプしてインタプリタを開始することができます

$ python3.7

出典: https://docs.python.org/ja/3/tutorial/interpreter.html#using-the-python-interpreter

linuxの勉強してなかったらわかんないと思う。公式ドキュメントとかこんなんばっかだから。諦めてlinux勉強しよう。

参考図書は例によってなんでも良いんだけど一応言っておくと俺が読んだのはこれ

まじで教科書みたいに全部書いてあって、あとで説明するけどGitの使い方とかもあってとても良かった。

Windowsを使ってる人、windowspythonは無理なのですぐに窓から投げ捨てよう。Linuxのコマンドが一つも使えないから。

Macは知らんがまぁある程度応用が効きそうだと言う話は聞く。でも初心者がいきなり応用しようとするな。Linuxを入れろ。

仮想環境

Linuxやったら今度は仮想環境を使える様になる必要がある。 Ubuntu環境のPython - python.jp

ここがとてもわかり易く解説してくれている。ちなみにvirtulaenvやらpyvenvやら仮想環境を作るツールは色々出てるけど、venvが標準なのでおとなしくvenvを使うと良い。あ、Anacondaもだめpipとcondaは全くの別なので、あれ?このパッケージ入れたけどimport出来ないぞ?あ、condaでインストールしてたわみたいなことが起こるので。

仮想環境使うと試しに触ってみたけどなんか全然使えねぇわみたいなパッケージを気兼ねなく削除することができる。

Gitを使う

使えないと話にならない。大体のパッケージはGithubで公開されてるのでGitとgithubの使い方がわかんないとどうしようもない。やれ。

公式ドキュメントを読めるようになる

次に公式ドキュメントを読める様にならなきゃいけない。Qiitaだったりブログだったりはざっと目を通すには良いが、その正確性だとか網羅性とかは信用してはいけない。結局公式ドキュメントを読むことになる。俺はいつの間にか読めるようになってた。多分上述の分野の勉強した後から読めるようになったんじゃないかと思う。

あと日本語なんてマイナー言語はどのドキュメントにも使われてない(相当でかいプロジェクトにしか邦訳はない)ので英語は必須。

もう君はpythonで開発ができる

ここまでやってようやく個人で開発ができる。作ったプログラムを配布したい? Python Packaging User Guide — Python Packaging User Guideを読もう。君ならもう読める。BeautifulSoupでスクレイピングがしたい? kondou.com - Beautiful Soup 4.2.0 Doc. 日本語訳 (2013-11-19最終更新)を読もう。コマンドを自分で作りたい? Argparse チュートリアル — Python 3.7.3rc1 ドキュメントを読もう。

加えて読んでおいたほうが良い本

pythonプロフェッショナルプログラミングはできれば読んでおいたほうがいい。

これはグループで開発する際のノウハウを主に書いた本だけど、個人でも使えるところは多いし、そもそも自分で使うパッケージが会社で開発されたものだったりすることが多いので読んでおいて損にはならない。

最後のほうとかめんどいので適当になったけど許して

migrate-exblog 2.0.0をリリースしました

github.com

知らない人向けに説明すると、これはエキサイトブログにははてなブログのようなエクスポート機能が無いので、スクレイプして他のブログに移行できる形式に変換するプログラムです。

今までの、単体テストも無くて、パラメータの設定の仕方も気持ち悪い仕様から大幅に変更しました。

今まで全部の投稿をとってくるのに、/m2005-01-01みたいな月ごとの投稿一覧ページを全部試してとってきてたんですけど、なんと/m1900-01-01/に全ての月ごとのアーカイブページのリストがあったんで、そこからとってくるようにしました。このおかけでだいぶ高速化できました。あ、ちなみに一回サーバーにリスエスト送ったら0.5秒休むようにしてます。

これで大体開発終了ですかね。まぁカード型のデザインとか、独特なスキン使ってるとエラー出るんですけど、正直使う人もいないしそこまでやってもなって感じです。

今後は勉強のためにdjangoでWebアプリ化でもしてみようかなと思います。

ほんとにこの開発を通じて良い経験になりました。使ってもらえるのが一番うれしいけどどうしたら有名になるんだろうか。宣伝?

pythonプロフェッショナルプログラミングを(大体)読んだ

読んだ。kindleで買ったら800円くらいポイントが付いてきたのでラッキー。

個人開発で限界を感じてる人におすすめ。

Pythonプロフェッショナルプログラミング 第3版

Pythonプロフェッショナルプログラミング 第3版

最近個人で開発しているが、pythonのパッケージ化とか、開発のお作法とか、テストの書き方とか、gitの使い方とか、なんにもわからなかったので買ったけどほんとに欲しいものが書いてあった。

前も調べたことが合ったんだけど、その時は旧版で、gitじゃなくてmercurialとかちょこちょこ微妙なトコが合ったが、改訂してからはgitになったのでとても使いやすくなった。

入門書みたいに、listのメソッドにはsortやappendなどがあって〜〜と全部書いている訳じゃないのが特に良かった。こういう機能があって、こういうように運用するといいですよ。詳しくはドキュメント見てくださいね。さっきの例えで言うとlist型があって、一気に値を保持できますよ。こういうときに使うと良くて、詳しいメソッドはドキュメントをみてね。みたいな。

こういう体裁を採ってるおかげで、実際に開発で使うときのノウハウが沢山載ってるのがとても良い。詳しいとこまで全部説明してたらいくら紙面があってもたりないしね。

一番重点的に読んだのはパッケージ化の所。ちょうどやりたかったしね。次点でテストかな。逆にチケット管理とか、チームで開発するときに重要になるようなところは流し読みしただけ。内容が濃いのでこの本を全部マスターすれば結構すごいプログラマになるんじゃないか?え?ならない?そう・・・

次はテストの実装とか、djangoを使ったwebアプリ化とかをやってみる。

venvのディレクトリ構造についての誤解

単純に馬鹿な誤解してただけなんですが、venvで仮想環境作るときに

python3 -m venv venv-dir

ってやると思う。 俺はvenv-dir以下で開発するのかと思ってたけどこれは違うらしい。つまり

venv-dir
└ lib
└ lib64
└ etc
└ .... #以上がvenvで作られるディレクトリ

└ プロジェクトのコードたち

みたいなディレクトリ構成になると思ってたけどこれは間違ってて、実は

プロジェクトのルートディレクトリ
└ venv-dir
└ プロジェクトのコードたち

が正しい構造らしい。 (; ・`д・´) ナ、ナンダッテー !! (`・д´・ (`・д´・ ;)

まぁこの認識さえ間違っている可能性はある。

でも考えてみればvenvはPATHの先頭に仮想環境のパスを追加するだけなので(うろ覚え)、venv-dirはPC内のどこにあってもいい。例えば(アホみたいだが)/boot に作ってもいい。俺が勘違いしてたように、venv-dir以下にコードを置く必要はない。

ここではvenvのフォルダ名をvenv-dirとしたけど、開発のお作法的には

# Environments
.env
.venv
env/
venv/
ENV/
env.bak/
venv.bak/

(出典: https://github.com/github/gitignore/blob/master/Python.gitignore )

のどれかを使うのがいいと思う。天下のgithubが言うんだからそうに違いない。

まぁエクスプローラーがスッキリする .envか .venv がいいかなとは個人的に思う。

pythonで画像をbase64エンコードしてimg タグに埋め込む

import base64 as bs
from pathlib import Path
IMG_TAG = '<img src="data:image/jpg;base64,{base64}"/><br>'
image_path = Path('path/to/somewhere')

def make_base64_tag(image_path):
    with image_path.open('rb') as f:
        enc = bs.b64encode(f.read())
        enc = enc.decode()
    return BASE64_URL.format(base64=enc)

以上です。

エキサイトブログをMovable Type形式でエクスポートするツールを公開しました

github.com

 タイトルの通りです。エキサイトブログにあった部活のブログを移行する際にまさかのエクスポート機能がないという糞仕様だったので自分で書いたのを改変して公開しました。なにがムカつくってインポート機能はあるところだよな。そういうとこやぞ。 FC2を経由してエクスポートはできるっぽいけどこれがあるから自前で実装していないのだろうか。ちなみになんでFC2経由でエクスポートできるのに自作したのかというと自分でやりたかったからです。あとFC2は新規にブログ作ってから1週間はエクスポートできない。(別のサイトも移行したんだけどそのとき使ったスクリプトが流用できそうだったのもある。)  これからmovable typeを利用したソフトを開発する人向けに言っとくと(いるのか?)これmovable typeのドキュメントになってる。movable typeという名前がブログの出力フォーマットと、CMS両方につかわれているので探すのがとても面倒くさい。なんかバージョンが4で、古いかもしれないけど知らん。

 スクレイピングして記事の内容集めてきてるんですけどまじでエキサイトブログのhtmlが汚すぎて内容の選別が大変でした。部活のブログのhtmlはまさかのtableタグで記事を管理してるのでほんとに汚い。htmlのデザインは全然詳しくないけどこれが良くないことだというのはわかる。

 まぁ糞仕様とかなんだかんだ言ってるけど、そのおかげでスキルが上がったのには感謝してる。綺麗だったらぱっと取ってきて終わりだっただろうし。この公開を通してgithubの使い方とかお作法とかpythonデバッグとかjupyterの使いどころとか学べたので楽しかった。

 READMEにも書いてあるけど現在はタイトル、本文、投稿日時のエクスポートしか対応してません。コメントとかカテゴリとかにも対応するかどうかは皆さんの反応にかかってます。正直自分はもう使わないので開発のモチベがない。反響があればやろうと思います。Webアプリケーション化とかやっても面白そう。

 みんなもこのツールを使って微妙にデザインのダサさが漂うエキサイトブログから脱出して、モダンなはてなブログに移行しよう!

 これ見て雇ってくれる企業とかねぇかな(期待)。

シン・ゴジラ の感想

いつかは見ようと思っていたシンゴジラをやっとみた。色々思うところはあったけど楽しかった。

思うところのなかでも特に言いたいことが「はよエヴァ作れ」ね。これは各所で言われているので俺からはこれ以上はいわない。

全編通して、ずっとエヴァヤシマ作戦を見てる感じだった。BGMもヤシマ作戦の使われてたしね。ヤシマ作戦のBGM汎用性高すぎだろ。割と普通にTVのBGMでも流れてるし。新劇場版のエヴァのCD全部持ってる俺としては他のBGMもめっちゃ好みだった、と思ってスタッフ調べてみたら音楽は鷺巣さんなのね。通りで聞いたことあるテイストだと思った。庵野はよシンエヴァ作れ。

ひたすら会議見させられるけどヤシマ作戦大好きな俺としてはもう会議が面白かった。会議室の全体をとりながらバックで「〜〜を確認」「目標〜〜しました」「〜〜を関係各所に通達」とか情報がながれこんでくるのが好き。エヴァでオペレーターたちがやってたあれ。最後の作戦行動よりむしろ会議が好き。ほんとにエヴァに毒されてしまったと自分でも思う。はよエヴァ作れ。

会議の内容も(グダグダさ方面での)リアリティがすごいあって、形式を踏まないと行動できない日本の民主主義ってのがひしひしと感じられる。射線上に民間人がでてきて射撃の可否を問うシーンで上司から上司へ電話が回されるシーンがあるんだけど、いや現場の報告ぐらい直接聞けるようにしとけよとか、そういう細かいところで現実感がでてくる。

見る前から「内閣総辞職ビーム」って聞いてたから今か今かと待ってたんだけどあれだったのか。なんかもっと間接的なもの(ビームによる不祥事とか)で総辞職かと思ったらもろ直撃で笑った。そういや憲法にそんな文言あったなぁ。試験では全く使わなかった知識がこういうとこで活きてくると楽しい。

まぁ肝心の作戦部分には賛否あるみたいだけどまぁ良いんじゃね。なんとかして(アルマゲドンの削岩機みたいな)もので穴開けて体に直接打ち込むシナリオにすればいいかとおもった。とはいえ俺はそういうもんだと思って楽しく見てました。楽しんだもの勝ち。

結論としてはエヴァ作れです。おしまい。

pythonではてなAPIを使って記事を投稿する

色々認証方式があるけど一番簡単なBASIC認証でやる

template = """<?xml version="1.0" encoding="utf-8"?>
<entry xmlns="http://www.w3.org/2005/Atom" xmlns:app="http://www.w3.org/2007/app">
<title>{title}</title>
<author><name>name</name></author>
<content type="text/plain">{body}</content>
 <updated>{date}</updated>
 <app:control>
     <app:draft>no</app:draft>
 </app:control>
 </entry>
"""
# ここでインデントするとprintで出力したときにおかしくなる。
# templateの{title}, {body}, {date}にそれぞれ値を入れる。
# nameは変えたりして試してみたけど特に違いがわからなかったのでそのままにしてる。
# dateの書式はdatetime.datetime.strftime('%Y-%m-%dT%H:%M:%S')でいける

uri = 'https://blog.hatena.ne.jp/{hatena_id}/{blog_id}/atom/entry'

# このブログで言うとhatena_id = 'arark', blog_id = 'arark.hatenadiary.jp' (ドメイン名)

api_key = '<api_key>'  # 設定に書いてある

import requests
from requests.auth import HTTPBasicAuth

res = requests.post(uri, auth=HTTPBasicAuth(hatena_id, api_key), data=template)

これでOK

uri変えたりすれば他のAPIでも使えると思う