先日、brew cleanupコマンドをすることで8GB近くも容量が空く事件がありました...
その後はこまめに
brew update brew upgrade brew cleanup
とやっていたのですが、
brew upgradeの中にbrew updateが含まれていることを知り、さらにはbrew upgradeコマンドのサブコマンド--cleanupがあることまで知りました。
つまり
brew update brew upgrade brew cleanup
の3つが
brew upgrade --cleanup
で、できてしまうんですね。最高です。
今日もやります。容量が無いので。もう意味がないことを知りながら。
ブログでのアウトプット習慣が染み付いてきてコード書きたい！！的な欲望が出てきました。そこで、目に見える成果としてWEBアプリケーションを作ってみることにしました。まずは公開する手順をさっさと身につけようと思い、Djangoをherokuにあげてみることにしました。これはその手順です。
ほぼこちらの記事通りにやりましたが、バージョンが違ったり、ところどころ躓いたところがあったので、 自分なりにアレンジしているところがあります。
仮想環境に入ります。 まずは、仮想環境を作成しDjangoをインストールする。
YOUR PC:workspace user$mkdir django_heroku YOUR PC:workspace user$python -m venv django_heroku/ YOUR PC:workspace user$cd django_heroku/ YOUR PC:django_heroku user$ source bin/activate (django_heroku) YOUR PC:django_heroku user$ pip install django (django_heroku) YOUR PC:django_heroku user$ pip install django-toolbelt
プロジェクトを作成し、マイグレーションをする
(django_heroku) YOUR PC:django_heroku user$ django-admin.py startproject config ./ (django_heroku) YOUR PC:django_heroku user$ python manage.py migrate
サーバを起動する
(django_heroku) YOUR PC:django_heroku user$ python manage.py runserver Performing system checks... System check identified no issues (0 silenced). June 16, 2018 - 07:19:32 Django version 2.0.6, using settings 'config.settings' Starting development server at http://127.0.0.1:8000/ Quit the server with CONTROL-C.
ブラウザを立ち上げて
http://127.0.0.1:8000/にアクセスし、下の画面が出れば成功。（versionによっては違う画面が出ることがあるかも知れません
vim .gitignoreでファイルを作成する
*.pyc staticfiles db.sqlite3
gitにコミットとプッシュする
git init git add . git commit -m "create Django app"
foremanが最新バージョンだと動かないらしいので、0.61をインストールする
gem install foreman -v 0.61
Procfileファイルとrequirements.txtファイルを作成する
echo "web: gunicorn config.wsgi --log-file -" > Procfile pip freeze > requirements.txt
vim config/settings.pyでsettings.pyの末尾に下記の内容を追加する
# Parse database configuration from $DATABASE_URL
import dj_database_url
db_from_env = dj_database_url.config()
DATABASES['default'].update(db_from_env)
# Honor the 'X-Forwarded-Proto' header for request.is_secure()
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
# Allow all host headers
ALLOWED_HOSTS = ['*']
# Static asset configuration
import os
BASE_DIR = os.path.dirname(os.path.abspath(__file__))
STATIC_ROOT = 'staticfiles'
STATIC_URL = '/static/'
STATICFILES_DIRS = (
os.path.join(BASE_DIR, 'static'),
)
vim config/wsgi.pyでwsgi.pyの内容を書き換える
"""
WSGI config for config project.
It exposes the WSGI callable as a module-level variable named ``application``.
For more information on this file, see
https://docs.djangoproject.com/en/2.0/howto/deployment/wsgi/
"""
import os
from dj_static import Cling #文を新しく記述する
from django.core.wsgi import get_wsgi_application
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "config.settings")
application = Cling(get_wsgi_application()) #文を変更する
Heroku Command Line Interface (CLI) をインストールしていない場合、インストールする
brew install heroku/brew/heroku
Herokuにログインしていない場合、ログインをする ユーザ名とパスワードは、Herokuアカウントを作成したときのもの
heroku login
Herokuアプリを作る
heroku create
Herokuの環境変数を設定する
heroku config:set DISABLE_COLLECTSTATIC=1
Heroku内でマイグレーションをする
heroku run python manage.py migrate
Herokuでアプリケーションが動いてるかを確認する
heroku open
これから開発頑張っていくぞ
pythonコマンドで起動させて
>>>import django >>>django.get_version() '2.0.6'
3月から5月末まで id:kakku22 カカカカック さんに技術ブログのメンターをお願いしていました。 2018年になって「アウトプットをする年にする」と自分の中で決めてから、週に一回ブログを書くことを目標として動いていました。しかし、一人でやっているうちに、「記事の質が低いのではないか」「構成が良くないんじゃないか」とか不安になることが多くなっていったんですね。そんなときに、カカカカック さんが「ブログメンティーを募集します」と呟いていたので、お願いすることにしてみました。
卒業するときに知ったのですが、カカカカック さんがブログメンターを始めてから3ヶ月続いた人は自分が初めてなんだそうです！長いことがいいことか悪いことかわかりませんが、初って嬉しいですね。笑 ここでは、良かったことや思い出に残っていることを書いてみようと思います。未来の自分自身のためにと、これからメンターをお願いしようかと思っている人たちのために、なにか参考になれば幸いです。
まずは自分が興味ある技術について質疑応答がありました。今、やり取りさせていただいたDMを読み返しながらかいていますが、自分はこんなことをやりたいと答えていたのかと面白くなります。 自分はこのようなものをあげていました。
この内で書いたのは、2.3つぐらいですね。 書き続けているうちに、「こんなネタを書いてみたい！」といろいろ思うようになるので、最初は少なくても大丈夫だと思います。
記事の質に関するやり取りの最中でしたが、
基本的には「過去の自分」もしくは「学んだことを忘れた未来の自分」に教える目的でブログを書けば，おのずと質は上がります
とおっしゃっていました。
自分がブログを書き始めた理由は、すぐ忘れる自分のためと、自分が困ったときに助けられたインターネットに貢献して、別の誰かの助けとなりたかったからです。この認識・感覚があっていて安心しました。
これは自分が持ち合わせていなかった価値観です。読んで助かって「ありがとう」と思うことはもちろんたくさんありましたが、シェアをするっていう行動を起こしたことまではありませんでしたので学びがありました。また、同じメンティーの方とも、SNS上で仲良くなり嬉しかったです。自然とお互いがRTやいいね！をして、励みにもなりました。
これでもかってぐらい、ポジティブフィードバックをいただけます。笑 GoogleCloudPlatformのCloud Vision APIに関する記事を1つ上げたあとにたくさん褒め言葉をいただけましたし、その後に10記事分になるんじゃないかってぐらい、横と縦に話題を広げてくれました。技術探究心がすごいですね…自分もこれからがんばります。
Open Graph Protocol（OGP）なんてものは自分は全く知りませんでした。TwitterやFBなどのSNSにシェアしたときにサムネイルが出るアレですね。Wordpressを使っていたときはOGPの設定がプラグインを使って手動だったので、設定がうまくいってないと出ませんでした。そのあたりの質問とか調査にも協力してくれました。
3ヶ月目に入るときに、自分の課題点を聞いたらちゃんと教えてくれました。いつも褒めてくださって嬉しいのですが、ちょっと厳しい視点も欲しくなったときに包み隠さず答えてくださったのはすごく嬉しかったです。なので、自分のだめなところ改善したほうがいいところはガンガン聞いてみましょう！
僕は記事のPV数が弱いことが課題でした。もちろん、バズやPV数を稼ぐことが目的ではないですが、多くの人に届けることは必要です。よく書く記事の傾向としてIoTなどを扱っていたので少しニッチな分野だったかなと思います。Webアプリやフロント側、Python、Rubyなど流行ってるプログラミング言語などに挑戦して扱っていけばよかったかなと思います。
自分が興味ある分野に関することを提供していただけます。自分はJavaScriptを業務で扱っていたので、Learn to code - for free | CodecademyのReactの記事を書いてみることを提案してもらいました。実際にやってみたところ非常に面白く、ブログの記事もスラスラと書けました。自分の興味ある分野を広げていただいて感謝しかありません。
好き勝手書いてきましたが、本当に楽しく過ごせた3ヶ月間でした。現在2700文字ぐらいですが、楽しく過ごせていなかったらここまでかけないと思います。社外にメンターがいるというのも非常に貴重な経験です。自分にサポートするメンバーが出てきたらどう接するかの学びもありました。 ブログでのアウトプットを通して、社内での信頼残高も上がりました（たぶん）。社内・社外問わずイベントに参加しインプットする姿勢、さらにはそれをアウトプットする姿勢が培われたのも自分の中で大きいです。感謝してもしきれません。これからも日々努力して成長していきたいと思います。 本当にありがとうございました。
5月の活動を振り返ってみます。
1月はこちら yoshitaku-jp.hatenablog.com
2月はこっち yoshitaku-jp.hatenablog.com
3月はこっち yoshitaku-jp.hatenablog.com
4月はこちらです yoshitaku-jp.hatenablog.com
ありがとうございます。 誰かの役に立てたなら嬉しい。
全然やれませんでした。 自分のコンフォートゾーンの少し外ぐらいのことにチャレンジてみようと思います。 なにか案があったら教えて欲しい…
社内でもくもく会の第二回を開催してみました。 今回は機械学習・AIに関するものを自分が触りたかったので、そこからもくもく案を考えました。 AWSやGoogleCloudPlatform（GCP）、MSなど各ベンダーでサービスを提供していますが、どこのソリューションを使うかは、自社内で触る機会が少ないGCPで実行してみました。
使ったものはこちら 花のデータセットを使用した画像の分類
作業内容
サンプルコードを実行してデータを Cloud Dataflow で前処理してから、この変換後のデータを使用して Cloud ML Engine でモデルをトレーニングします。このトレーニング後のモデルを Cloud ML Engine にデプロイし、予測リクエストを送信してモデルをテストします。 このサンプル データセットに収録されているのは、ごく少数の画像（最大 3,600 件）です。機械学習技術を使用して正確な分類モデルを一から適切にトレーニングするには、これよりも多くのデータが必要です。ここでは、転移学習と呼ばれるアプローチを代わりに使用します。転移学習では、あらかじめトレーニングされたモデルを使用して画像の特徴を抽出し、これを使用して新しい分類器をトレーニングします。このチュートリアルでは、Inception という事前トレーニング済みモデルを使用します。
結論から言ってしまうのですが、このチュートリアルは途中でエラーを起こしてしまうので終わらせることが出来ませんでした。
ブラウザ上で、GCPの操作や開発が行えるツールがCloudShellです。SDK落としたり、ローカルで開発環境を開く必要もないので便利でした。ただブラウザが狭くなるのは…仕方ないか。
今回は一つアカウントを作り、そのアカウントを共有して作業をおこなう予定でしたが、CloudShellのセッションを取り合ってしまってうまく作業が進みませんでした。
今回のもくもく会は7名ほどで実行したのですが、全員がこの項目以降進めなくなってしまいました。 エラーも「temp_location」が無いぞというエラーだったり、実行途中にCloudShellが落ちてしまうものだったり、原因がバラバラでつかめませんでした。
原因がつかめていない時点で、推測を書くのもどうかと思うのですが、メモとして書いておきます。 今回使用したcloudml-samples/flowers/ ですが、各ファイルの最終コミットが4ヶ月以上前のものばかりです。ドキュメントの整備・整合性を含め、Github上で整備されていないのかなぁと思いました。
今回は社内もくもく会でGoogle Cloud Platformを使ってみました。
今回の学びとしては、
機械学習・AI分野に対する知見が増えなかったのは残念ですが、ブラウザ上でCloud Shellというものが扱えることが知れたのも良かったですね。 そこまで使いこなせているわけではないですがAWSに慣れると、GCPのUIや用語がわからなくて辛いです…
NoSQLの基礎知識について読んでいます。
NOSQLの基礎知識 (ビッグデータを活かすデータベース技術)
今回はカラム指向形型についてまとめます。
カラム指向型はキーバリュー型を拡張して、行と列の概念を持ったものです。もとから列が定義されているのではなく、複数のキーとバリューを、行キーと呼ばれる識別子でグループ化したものです。そして、グループ化されたここのキーバリューを「カラム」とよんでいます。
行キーとカラムをまとめたものを、カラムファミリーと呼びます。 カラムファミリーは事前に定義する必要があります。しかし、カラム名は定義する必要がなく、データを挿入するタイミングで好きなものを指定することができます。
カラム名に時間とともに変化するものを設定することもできる。さらに、リレーショナルデータベースと明確に違うところはデータの発生に応じて動的にカラムを追加することができる。
キーバリュー型と同様にスケールアウトに適しています。データを複数のサーバに分割して配置し、データを複製することが出、データ感の関係性を維持するリレーショナルデータベースをよりも簡単にできるからです。