Hy と Python の version について
Hy の install 時に Python version で少し困ったりしたのでメモ
普通に Python 3.7.0 の環境で Hy を pip install して実行すると
ImportError: invalid flags 1531398560 in 'hy.core.language'
こうなったり、または一回は実行できるけど二度目は失敗する、みたいなことになる
Hy 0.14.0 は Python 3.7.0 に対応していないためにこのエラーは起きているようで
これより後に 3.7.0 対応が行われている
と言うわけで対応としては公式通り、基本的には
$ pip install hy
よりも
$ pip install git+https://github.com/hylang/hy.git
の方が良さげ
Spacemacs の install で嵌ったりした
最近 Lisp 方言を書く機会が多いので重い腰を上げて Emacs を入れました
といっても素の Emacs を育てるには Vim に染まりすぎたので
Spacemacs という Emacs の distribution に頼ることにしました
嵌ったところ
公式にしたがって ~/.emacs.d に clone したのですが
Error (use-package): org-projectile :config: Symbol's function definition is void "projectile-global-mode"
的なことを言われたり言われなかったり、mode がうまく切り替わらなかったりして嵌ってました
で、spacemacs 自体を develop に切り替えることでうまくいきました
予想ですが、この PR が関係してそうだなと
$ cd ~/.emacs.d $ git checkout develop
このあと一応 dotspacemacs/install し直してます
その他
思ったより Spacemacs 良かったです
C-x C-c と C-g だけ覚えとけばなんとかなる
Docker で mediawiki 立てて oauth extension 入れるまで
前も似たようなこと書いた気がするけど...
検証用に local で一時的に立ててるものなので色々ご注意ください。
build
docker hub から引っ張ってくると mediawiki が古い (多分) ので公式 repository を clone して build します
$ git clone https://github.com/wikimedia/mediawiki-docker.git $ docker build --rm -t mediawiki:latest mediawiki-docker/stable/
run
立てます、動けばいいので色々適当です
$ docker run -it -d -e MYSQL_ROOT_PASSWORD="root" --name mysql mysql $ docker run -it -d -e MEDIAWIKI_DB_PASSWORD="root" -e MEDIAWIKI_DB_TYPE="mysql" -p 8080:80 --link mysql:mysql --name mediawiki mediawiki:latest
ここからは http://localhost:8080 にアクセスしつつ色々進めます。
途中に入れる db への接続先は
$ docker inspect -f '{{ .NetworkSettings.IPAddress }}' mysql最後まで行くと LocalSettings.php 入れてねって言われます。
local settings
今回は oauth extension をとにかく早く動かしたかったので mail 系を全部無効にしました (しないと認証求められるので)
$wgEnableEmail = false; $wgEnableUserEmail = false; # UPO ... $wgEmailAuthentication = false;
入れます
$ docker cp ./LocalSettings.php mediawiki:/var/www/html/
oauth extension
OAuth extension を download してきます
ここら辺です
Download MediaWiki extension - MediaWiki
適当なところに copy して解凍します
$ docker cp ./OAuth-*.tar.gz mediawiki:/tmp/ $ docker exec mediawiki tar xzf /tmp/OAuth-*.tar.gz -C /var/www/html/extensions
LocalSettings.php に設定を追記して update します
とりあえず誰でも consumer を追加できるようにしたいのでそんな感じにします
$ docker exec mediawiki sh -c "echo \"wfLoadExtension( 'OAuth' );\" >> /var/www/html/LocalSettings.php" $ docker exec mediawiki bash -c "echo $'\$wgGroupPermissions[\'user\'][\'mwoauthproposeconsumer\'] = true;' >> /var/www/html/LocalSettings.php" $ docker exec mediawiki php /var/www/html/maintenance/update.php
consumer registration は http://localhost:8080/index.php/Special:OAuthConsumerRegistration
BitBucket で OAuth 1 での認証がうまく行かなかった話
結論
timestamp が float だった
経緯
私が作っている nim の oauth library を修正したところ
bitbucket の例がうまく動かなかった (というか bitbucket は多分ずいぶん昔から動いていなかった) ので調査していて分かったのでメモ
問題の切り分けに時間がかかった要因としては
の例は動いていた、という点があります。
概要
いくつかの bitbucket x oauth 1 の例から正常に動く以下の例を参考に
Bitbucket OAuth 1 Tutorial — Requests-OAuthlib 1.0.0 documentation
送られているヘッダーを見比べた結果
- Requests-OAuthlib
oauth_timestamp=\"1530407158\",
- oauth
oauth_timestamp=\"1530407309.0\",
となっていて、ここが原因でした。
先ほどの Twitter 等のサービスは、timestamp が float でも受け入れていたということのようです。
わかれば単純ですけど、bitbucket は理由を返してくれないので何故こけてるのかが分からずかなり時間がかかりました...
Red で http request を行う方法
Red programming language で http request を行う方法がちょっと分かりづらかったのでメモ
GET
本当にシンプルな GET
>> read http://localhost:8080/api
== {{"status":"ok"}}header の追加など必要な場合
>> write http://localhost:8080/api [GET [
Accept: "application/json"
] ""]
== {{"status":"ok"}}(読みやすいように実際の出力を一部修正してます)
POST
>> write http://localhost:8080/api [POST [
Accept: "application/json"
] {{"data": "data"}}]
== {{"status":"ok"}}
Others
他は一緒です。
ただ、PATCH と DELETE は 0.6.3 時点で対応されていないのでご注意ください。
>> write http://localhost:8080/api [PUT [
Accept: "application/json"
] ""]
== {{"status":"ok"}}
>> write http://localhost:8080/api [PATCH [
Accept: "application/json"
] ""]
*** Internal Error: reserved for future use (or not yet implemented)
*** Where: write
*** Stack:
>> write http://localhost:8080/api [DELETE [
Accept: "application/json"
] ""]
*** Internal Error: reserved for future use (or not yet implemented)
*** Where: write
*** Stack:
refinement
read/write は refinement による挙動の違いがあります。
refinement の一覧はこの辺りで確認できます
read, write 共に binary, lines, info refinement が実装されてます
ちなみに write は append と part もエラー発生せずに通るのですが、みた感じ実装されてない気がします
binary
データを 16 進形式で返します
>> read/binary http://localhost:8080/api
== #{7B22737461747573223A226F6B227D}
lines
文字列を改行で区切って block で返します
>> read/lines http://localhost:8080/api == ["text" "text" "text"]
info
名前の通り
>> info: read/info http://localhost:8080/api
== [200 #(
X-Content-Type-Options: "nosniff"
Server: "WEBrick...
>> print info
200 X-Content-Type-Options: "nosniff"
Server: "WEBrick/1.3.1 (Ruby/2.4.2/2017-09-14)"
Content-Length: "15"
Content-Type: "application/json"
Connection: "close"
Date: "Sun, 03 Dec 2017 09:47:41 GMT" {"status":"ok"}詳しいことは実装見るのが一番早いので、simple-io あたりをご覧ください。
YAPC::Fukuoka 2017 HAKATA 前夜祭で LT してきました
最近 GitHub から緑が消え始めてて危機感しか感じません。
それはさておき、
YAPC::Fukuoka 2017 HAKATA に参加して来たのでその感想を書きます。
前夜祭
「Possibility of terminal」 という題で Terminal (というか prompt) の可能性について話してきました。
この手の話がどう受け止められるか (というか受けるのか) 分からなかったので結構心配なところはありましたが、
笑っていただけた部分もあったようで良かったです。
反省点は色々あるので、それは次の機会に改善します。
ちなみに普通に Terminal に表示するとこんな感じでした。
初参加だったので知り合いもいないし、Perl も知らないし福岡に住んでないし、なんで参加したのかよく分からない人間筆頭でしたが
発表したことである程度「なんか見たことある」人になっていたようで助かりました。
当日
会場がすごかった...
いくつか印象に残った Talk について。
ウェブセキュリティの最近の話題早分かり
脆弱性の紹介とデモの手際が良くて非常に面白かったです。
これだけでも福岡に行った甲斐あったなぁという感じでした。
はてなブログ最近の開発テクニックと最新の開発風景のご紹介
色々と感銘を受ける部分は多かったですが、
デザイナーとの開発のくだりがかなり良かったです。
デザイナーがデザイン周りのレイアウトとか組めたら良いよねって言うのは簡単なんですけど、
そこから先導入して行くのってとても体力が要るので、
言うだけで終わってたらダメだよなぁと感じた Talk でした。
あとコードレビューが遅い PR に未経験歓迎がつくの、なかなか良いですね。使っていきたい
The plan of Aniki 2.0
ORM にありがちな問題、よく分からないクエリ発行あたりはあるなぁ...って感想でした。
それに対する解決策としての Aniki 1.0 の特徴もなかなか良さそうに感じました。
Phantom Row Object, 面白そうですね。
umeda.apk #3 に参加してきました
umeda.apk #3 に参加してきたので、その感想です。
Best Practices to Slim Down Your App Size
前々から少し話題になっていたので知ってはいましたが、
やはり Cancellation Rates vs. Download Size と、
Uninstall Rates vs. Installed Size のグラフは結構印象的でした。
自分自身もストレージに余裕なくなると使ってないものでサイズがでかいものから消すので
まぁそりゃそうだよねって話ではありますが...
あと APK Analyzer 便利ですね。
ユーザーが敏感な割に作ってる側が鈍感なことが多いので、
ここら辺は APK Analyzer とか使いつつエンジニアから提案した方が良さそうです。
Speeding up your Android Gradle builds
Multi-module project はあまりやったことが無かったものの、
api と implementation の違いはなるほど、という感じでした。
Slow builds are not normal というフレーズは、言われてみればまぁそうだよね...という感じ。
2 年前くらいに「ビルド遅くない？」って言ってたのを思い出しました。
ただ 10 分かかるビルドは見たことがない...
info はよく使うものの、profile と dry-run は見たことが無かったので
これは使っていきたいです。
Actions On Google
Google Assistant の設計の話が印象的でした。
本や映画の脚本を書くように、ユーザーとの会話を掘り下げていきながら設計するあたり、
今までの設計とは全く異なるものを要求されそうで面白いですね。
これはマネージャーやデザイナーも知っておくべきだと感じました。
Api.ai は一回プロジェクト作成して放置してしまっているので、
近々試してみようかなと思います。
あと、アプリ探してもらう / 探すのがちょっと難しそうだなという印象を受けました。
Kotlin in Google I/O 2017
今何かと話題の Kotlin の話。
CyberAgent さんの FRESH! で Kotlin が採用されていて、
Kotlin M11 の時期で本格的に開発が行われているというのはやっぱり驚きでした。
自分の GitLab の記録を見る限り、
一番初めに Kotlin のアプリが commit されているのが今から一年半くらい前、
なので自分がちゃんと書き始めたくらいにサービスロンチくらいの勢いでした。
Kotlin を採用するにしろ、Java の知識が必要というのはとても大事なことだと思います。
開発していても絶対に必要になるし、Kotlin から入るにしても Java の勉強は必要。
個人的には、「なんとなく Java が苦手 / 嫌いだから」で入るのは辛いと思っています。
そういう人少ないかもしれませんが。
Swift とは似て非なる言語で共通化できないというのも納得できる話でした。
「Swift を使っている iOS エンジニアが Android に入る際、Kotlin から入ると心理的に少しやりやすいかも」
くらいだと思っています。大分前にそんな感じの話を社内でしましたが、その時の他のエンジニアからの評価もそんなものだったかと。
いま Swift を使ってアプリ開発をしている iOS エンジニアが興味を持つきっかけにはなり得ると思います。
Kotlin の自由度が高いという話は実務で確かに問題になりそうな話でした。
ルールを決める際は是非 Kotlin っぽいものを選んでいきたいですね。
あと Kotlin 学習の例を見て、
社内で広めるならやっぱりこれくらいしないとなぁ...と感じました。
Rust でも Go でも Kotlin でも、「やってみたい」止まりな人は多いので、
そのあたりを巻き込んで盛り上げていけたらと思います。
LT
ここからは飲みながら話しながら聞いていたのでちょっとうろ覚えで書きます。
Cool Tips for Firebase
スピード感がよくてとても面白かったです。
Remote Config で Locale によってアプリの色変えるみたいな話がちょっとあって、
そういうのやりたいなーと思いました。
Layout ファイルのメンテナンスについて
Layout xml の行数をいかに削減するかという話。
前半はなるほどなーと思って聞いていたものの、
後半は、そこまでする...？という感じでかなり盛り上がっていました。
What's new Android Wear
Android Wear の動向の話。
Android Wear 2.0 の話とか...スタンドアロンアプリの話とかされていた記憶があります...
Android Wear つけてる人ー！みたいな質問で全然手をあげてなかったのは正直笑いました。
持ってなくてすみません...
懇親会 (歓談)
自分が話した人がたまたまそういう人ばかりだったのかもしれませんが、
Java / Kotlin で、普段業務でアプリ書いてますって人があまりいなくて、
サーバーサイドのエンジニアだったり、Unity のエンジニアだったりしたのが印象的でした。
懇親会でも Kotlin の話がよく出ていて、注目されているようで嬉しかったです。
あと、スコープ関数の使い所がいまいち掴めないんですよねみたいな話も聞いたりしました。
スコープ関数が使ってあるコードを見て始めたばかりの人が悩んだり、使い所に困ったりというのは、
Python の内包表記に似た感じを受けました。
これは割と色々な言語にあることだと思っていて、
しばらく書いていると「ここってなんかしっくりこないんだよなー」みたいなところが出てきて、
その時によりそれっぽい書き方を調べたりするので、
個人的にはスコープ関数はそんな感じでも遅くないんじゃないかなーと思っています。
最後に
最初から最後まで非常に楽しい勉強会でした。
最終的に結構遅い時間までお話しさせてもらいました。
ありがとうございました！
