へっぽこびんぼう野郎のnewbie日記

けろけーろ(´・ω・`)! #vZkt8fc6J

さくっとバーンダウンチャート(Burn down chart)を生成してくれるGoogle Spread Sheetをつくりました

こんなかんじです。

f:id:haruharu1:20181022210746p:plain

数値を変更すると、自動的にグラフも変更されます。

f:id:haruharu1:20181022210831p:plain

説明

入力するべき欄 説明
Start 開始日を入れてください。
Expire 期限切れになる日を入れてください。ここでの01/02は、01/01の23:59までにやるという意味です。
Quantity 全体の量です。なんでもいいです。参考書ならページ数など、作業量を数値化したものをここに入れてください。
Amount 毎日書いてください。これをもとに青色のグラフが生成されます。

 

自動的に計算されるやつ 説明
DayAvr 入力した情報をもとに計算された、1日にやるべき量です。
Quota その日までに残っているはずの量です。これを上回ると進捗が遅れており、これを下回ることを目標にします。

 

その他 説明
OffSet 開始日からどのくらい離れているかを示します。
W 曜日です。

 

このへんの名前が気に入らない場合は自由に変更してください。

スプレッドシート

docs.google.com

これをコピーして使ってください。

366日間まで対応しています。

プログラマっていうか問題解決者になるべきなんだろうなって思った

Youtubeのサジェストで↓が上がってきたから「何言ってんだコイツ。バカだな」って感じで見に行ったら「プログラマになるな。Problem Solverになれ」って言ってて中身全然違うじゃねーか釣りタイトルかと思いつつ「た〜しかに」って感じた。

www.youtube.com

今までもなんか雰囲気でそう感じてたけど、Problem Solverっていう言葉を聞いて、究極的に自分の中でプログラミング系と現実系が高度に連結しあって体系化された。(ぶっちゃけこのYoutubeの人はじゃっかんうさんくさいけど、誰が言ったとかは気にしない。大事なのはProblem Solverという心)

実際コードなんて誰でも書ける。最悪の場合でもHelloWorldなら誰でもできる。なんか色々な技術、現実に横たわる異常に複雑な問題と比べて見たら朝飯前だと思う。

数学でアナロジーすると、わけわからん技術があってそれを勉強するというのも、単なる1個の問題で、何かをわかるというのは要は「それを解く」ことなんだろうなという感じで、今まで自分の中でモヤっとしていたものが、うまいこと言葉として具現化して、思考の表面にヌルッと出てきたように思える。

「別にコード書く必要ない」とかじゃなく、プログラミング技術を研磨するのは引き続きやった方がいいし、問題解決のためにプログラミング使わなさ過ぎるとコーディングの腕がガタつくけど、「これを実装するぞ〜」って考えるよりは、「何が問題か知って、それをボコスカ退治していく」って考えると、応用範囲広いように思える。

あまりにも思想が高尚すぎて、今の自分の身の丈に合ってなさすぎる気ワッフルだけど、ちゃんと問題解決者になれるといいなとおもいました🌻

とりあえず朝早起きできない問題から解決していきます……

技術書典5の全サークルの頒布物のリストを勝手につくりました

1サークルごとにクリックするのがめんどくさかったので、公式サイトのAPIを勝手に使って、適当にtableタグで囲いました。

本来なら画像はそのままダウンロードするべきではないかもしれませんが、負荷をかけるとよくないと思い、保存してあります。言ってもらえれば削除いたします。

2018/10/05 21:00 時点でのものです。なので当時まだサイトを変更していない人のものは無いと思います。

更新はするかどうかわかりません。

↓こんな感じで出ます

f:id:haruharu1:20181005220538p:plain

↓ ダウンロード先です。

[削除しました]

追記:

2018/10/07 23:45に取得したデータで再度作成しました。

[削除しました]

or

[削除しました]

適当に解凍して開いてください。

追記:

終わったので削除しました。

1分以内で作業が終了する米の炊き方 〜「線で計るのとかめんどくさい」とか言っちゃうズボラな人におくる炊飯器での米の炊き方〜

米を何合か確認して、その後水を線まで入れるのってめんどくさくないですか??

ぼくはそれがめんどくさいので、線は使ってません。

まず米と水の比率って、大体米1に対して水1〜1.2であればいいらしいです。体積の話です(白米の場合。それ以外はしらない)

なので米が200mlだったら、水は200ml〜240mlにすればいいわけです。

ぼくは、米をすくうための計量カップを使って米をすくい、まぁだいたいこれで1杯だなと思ったらそのまま炊飯釜に入れてます。

多く炊きたいときはさらにもう1回すくっています。

そのまま米をふつうに手で釜の中で研ぎます。じゃぶじゃぶ。最近のはそんなに研がなくていいはずなので、ぼくは1回研いだら終わりにしてます。

そして釜の中の研いだあとの水をジャーッとシンクに流します。もちろん米が流れていかない程度にながします。全部の水を流さず、ある程度流れたらあとは適当でいいです。

その後、水を、さっき米をすくった計量カップ1杯入れます。さっき2杯米をいれた場合は水も2杯3杯米を入れたなら3杯というふうに入れます。

そのまま釜を炊飯器に入れてボタンを押します。使った計量カップは洗ったのを乾かすところにでも置いておきます。

 ↓

_人人人人人人人人人人人人人_
> ふっくらできあがり!! <
 ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^ ̄

解説

研いだ後、水をジャーッと適当にシンクに流しているのは「多少残ってもそんなにおいしさに影響がないから」です。

その後は、米1に対し、水1.2をこえないようにしたいけど、水1は超えさせたいので、水1くらい(1杯)を釜に入れています。

そうすると研いだ後の余った水と合わさりいい感じになります。

シンクに流すときにしっかり水を切った場合は、水1より気持ち多めに入れます。あまりにもてっきとーに水を切っていて、めっちゃ残っとるがなって感じたのなら水1弱ぐらいを入れます。

米を2杯分炊くときは、もっと雑に水を入れても問題ないと思います。

ぼくがこのやり方で失敗したのは、最初にやり方を思いついた1回だけです。その後5年ぐらい炊いてますが、一度も失敗していません。

最初の1回の失敗は、水を1.2弱入れたらふにゃふにゃになったやつです。研ぎ汁の残りのことを忘れてたので、水が1.2よりも多く入ってしまっていました。その最初の入れすぎたことを後悔してからは、水1にしてます。

それ以来、毎回固くもなくやわらかすぎず、おいしくたけています。

味にうるさい人は水の量を毎回微調整してみてください。微調整の際には二分探索がオススメです。

水や米の量が雑でもいい理由は

計量カップの底面積の方が、釜の底面積よりはるかに小さいので、計量カップで線の位置が5cmずれても、釜の1cmのズレよりも小さいからです。 *1

ちなみに高さ5cmというのは約1杯分なので、計量カップだとそんなにズレることはありえないです。

まぁそんなわけで、釜の線での1mmのズレと戦うより、計量カップでの5mmと戦った方が楽なのは確定的に明らかです。また、釜の目盛りを斜め上から見ると、余計にミスりやすいです。なのでたまに失敗することがあるのだと思います。わざわざ水平にして目をこらしたりすると、それだけ時間を食います。

つまりぼくのやり方だと、5倍適当でもいいわけです。だから早く終わります。

↓これぐらい違います。(この黒い線の中に水の表面をもってこなければいけないと考えると、上の方の線はつらいことがわかります)



↓こっちはもう1つの例



メリット

とにかく作業がはやくおわります。

釜の中の線で計ると、線に水がくるまでどのくらい入れればいいのかわからなくなって、水をちょっとずつ入れて「もうちょっと」「入れすぎた」「水捨てよ」「もうちょっと」のような作業をすることが多いと思います。米を炊くときに一番時間を食うのがこれなので、カップで水の量を計ることで(しかも目盛りを特に見ないし)ものすごい時間短縮されます。

早すぎるので↓みたいな感じで対応されることもあります。

X「ごはんたいてよ」

ぼく「おっけー」

米すくう(10秒) → 米とぐ(20秒) → 水流す(10秒) → 水入れる(10秒) → ピッ(5秒)

ぼく「〜〜♪ ゲームの続きしよ♪」

X「あれ、なんでゲームしてるの?米たくっていったのに……」

ぼく「たいたよ」

X「うそつき。そんなに早く終わるわけないじゃん。終わってるだとッ!!?」

X「ちゃんと研いだ?」

ぼく「研いだよ」

X「線で計った?」

ぼく「はかってないよ。カップでやったから」

X「うわ絶対失敗するやつじゃん。最悪だ」

ぼく「だいじょうぶなのに……」

〜40分後〜

X「なんでちゃんと炊けてるの……しかもおいしいし……」

最高にドヤ顔できます。わけのわからない特殊能力持ちだと思われます。おためしあれ。

あと、当然ですが別に計量カップでなくてもできます。

茶碗とか紙コップとかお玉とかでもできるので、キャンプに行ったときに「計量カップ忘れた…」とかなっても紙コップで計って炊くことでヒーローになれます(なったことないけど)

個人的に、日本全体でこれが普通じゃないのがおかしいと思います。炊飯器の発明という文明の進歩によって、米の炊き方について日本人全体が退化したように感じられます。

手順まとめ

米を計量カップでX杯すくって釜に入れる
 ↓
米をとぐ
 ↓
研いだあと水を捨てる
 ↓
米をすくったときの計量カップで、水をX杯すくって釜に入れる
 ↓
炊飯器に釜をセットして炊飯ボタンを押す
 ↓
炊けるまでまつ
 ↓
いぇいいぇいいぇあ♪

楽だし簡単だし早く終わるしおいしく炊けるのでマジでオススメです。あ、もちろん、炊けたあとはむらしてください。

免責

このやり方でもし仮に失敗したとしても「米返せ」などということに応じることはできません。

たとえば「キャンプ行ってドヤ顔でおまえの言う通りやったら、米カチコチになって赤っ恥かいたやんけ!」って文句を言われても「わろた」って返します。ご注意ください。

では楽しい炊飯ライフを!

*1:厳密には「底面積」ではないけど、こまけぇこたぁいいんだよ。5倍という数値も特に根拠はない。雰囲気5倍っぽいから

JavaやPHPのハッカソンに潜り込んでPythonにリプレイスしてきた話

先日忍び込んだハッカソンで、「Java+Spring Frameworkで書かれたこのサンプルコードか、PHP+Laravelで書かれたこのサンプルコードを参考に何かつくってください」というお題をもらったので、朝から夕方まで7時間弱で食事は水オンリーで作業した結果、Python+Djangoでリプレイス作業をしたという成果をだして、気づいたことがあったのでとりあえずブログに書きます。成果はGitHubにあがってますが、汚いので見ないでほしいです。あとそのままでは動きません。pipで必要そうなライブラリをインストールしてください。

書く前の知識

  • Javaは書いたことある
  • Tomcatは知っている
  • SpringBoot自体は実行したことは1回ある
  • PHPは知らない
  • Spring Framework何も知らない
  • pom.xmlとはなんなのか
  • LTIやCaliperというIMC Globalという団体が作ってる規格がよくわからない(そもそもこれがメイン)

得られた知識

Java関係のもの

  • pom.xmlは、NPMでいうpackage.jsonみたいなもん
  • Spring Frameworkの中にはTomcatがあるものもある
  • DI使われていて便利そうだった。ただServiceの使われ方が何かおかしいように感じた
  • Javaはやっぱり冗長だった。Modelのところにgetなんたらとかが大量にあって悲しく感じた
  • RepositoryでのCrudRepositoryは便利そうな感じがしたけど、Djangoの文化と違いすぎてやるならフレームワークを作るところからやる必要を感じた
  • Spring Bootでのエントリーポイントが、PythonでいうWSGIみたいな感じで萌えポイントだった
  • SpringのControllerで、アノテーションにRequestMappingがあるのはいいなと思った(いまさら感)
  • IntelliJは良い

PHP関係のもの

  • 引き続き知らない

JavaPHP関係以外で得られた知識

  • LTIは要はHTTPのセッションに何入れるかのやつ。それとOAuth2
  • CaliperはCaliper(日本人はみんなそんなに知らないということがわかった)

パワーコードの教訓として得られたもの

パワーコードは実践では良くない

Spring Frameworkのことを全然知らないままやったので、何がどうなっているかわからないまま書き始めていた。

それで「とりあえず」と最初に決めたことにあとあとまで引きずられてしまった。たとえば最初はHello Worldからやったんだけど、そのHello Worldの書き方を最後まで継承し、コピペでいとも簡単に増殖した。

わからない→わかった!→じゃあこの書き方まずいよね→まぁいいか

というスパイラルが繰り返された結果、負債につぐ負債が誕生した。

たとえばViewを書くときに、最初はHello Worldからやったので、View(DjangoのView。Spring FrameworkではController)はクラスから作らず、関数で書いていた。↓こんなの

def index(request):
    return HttpResponse("Hello World")

ここにロジックを追加(個人的にロジックはここに集約すべきではないと思うけど)して、あとからテンプレートを追加することになったので、とりあえずテンプレートにコンテキストを渡せるものを作成することにした。

このへんで、サンプルのJavaコードで使われている「model」には、Djangoで使われているコンテキストの役割もあるということが明確に判明した。

それと同時に、ThymeleafというSpring Frameworkの中で使われるテンプレートがあることを知った。書き方はunderscoreやJinja2とは違って、どっちかって言うとWPFxamlみたいな感じ。

def my_render(template_file, modellike):
    template = Template('<html>foo</html>')
    html = template.render(Context({}))
    return html

def index(request):
    # ~~~ ロジック ~~~
    return my_render("index.html", model)

この状態から、ファイルからロードしてレンダリングする場合に、テンプレートの文字列をいちいちロードするのがめんどくさいので、ファイルをその場でオープンするという荒業を使っていた。

def my_render(template_file, modellike):
    source = open('app/templates' + template_file).read()
    template = Template(source)
    html = template.render(Context(modellike))
    return html

def index(request):
    # ~~~ ロジック ~~~
    return my_render("index.html", model)

そして、ここのindex関数部分がコピペでどんどん増えていく。

最初からDjangoで用意されていたものを使えばいいという話だけど、そもそもわかってない状態から作り始めてこの時点で「こういうふうに書くのがSpring Web MVC Frameworkというやつらしい」ということを理解したので、最初からそういうふうに作ることは知識的に無理だった。

なので、こんな感じでどんどん最初のものから負債が溜まっていく。0.1の瑕疵が最終的に全てを食い尽くすモンスターになっていった。

そのため、初期ではわずかしか行わなかったデバッグ作業も、終盤では多く含まれていた。つらい。

他人が書いたいいところを活かせず、自分の領域にすべて持ち込んでしまう

Spring FrameworkにはどうやらDIがあるというのを知ったけど、これを時間内に実装するのは無理だと判断して無視して実装していった結果、Pythonの方で冗長になり、何の生産性もないクラスがいくつかできあがってしまった。

逆に明確にDIを理解していないことが判明したことはよかった。

いわゆる抽象的な概念の知識が増えない

時間に追われていることもあって、既知の知識の範囲内でコーディングすることしかできなかった。

新しい難しい概念で腰を落ち着かせて考えるべきものは、こういうコードの書き方では手に入れられないなと思った。

今回得られた知識は、最初からある程度知っていた知識を焼き直したぐらいのものだった。

そういう面から見ると、業務とは直接関係ない勉強というのは重要だと思った。

時間管理は重要だった

「これは絶対無理。これはいける。これはできるけど時間的にキツいし、なくてもいいから切り捨て」という判断がだいじだった。

「この領域は何分でできるか。1個で5分なら、5個で完成だから15分くらいかな?」「残タスクはどれだけかマークダウンで洗い出し」というように見積もって、時計をときおり見ながらタスクをこなしていった。

タスクの洗い出しは、各領域を整頓するために脳からシリアライズしたぐらいで、途中で完全に全体構造が見えてからは全く必要なり、バージョン14時ぐらいで更新停止した。

ものすごく疲れる

タスクが完了してから、空腹と頭痛と体のだるさを一気に感じて死にそうだった。

帰りの電車で座れなくて「アアアアア」とゾンビみたいになっていた。

たぶんいつもやってる仕事よりやや簡単だったのでゾーンに入っていたのだと思っている。

時間管理の結果「飯を食う時間は無駄」と判断して休憩なしでやっていたので、こういう作業の仕方ばっかりやってると体を壊しそう。

ライブラリを読むのは正義

他人が書いたライブラリの中でエラーが発生したときは、まず読み、意味がわからなかったらググり、エラーの意味がわかるけどなんで出ているのかわからない場合、ライブラリの中でデバッグするという挑戦が必要だと思った。

それで仕様がわかったりしてた。(ちなみにハッカソンではあと5分しかないのに、なんでエラーになるのかわからないところがあって、最終的にライブラリの中身を編集して完成させるという暴挙に出た)

推論重要

「こうなってる?→なってたらここはこうなって、こっちはこうなってるはず→なってた!!!」というプロセスを繰り返せていて、特に何もドキュメントを読むことなくSpring Frameworkの外観を把握できた。なので今ドキュメントを読むと相当いろんなことがわかるようになっていると思っている。

新しいことを学ぶときは他人が書いたコードが一番勉強になる

ドキュメントを読むより、人が時間かけて書いてくれたコードをガンガン読んだ方がドキュメントより正確だし、自分で思考して推論していけるのでよかったと思う。

たぶんドキュメントを読んで自分でSpring Frameworkの環境を構築してJavaで書いていくより、効率的に学習できた。

ただし、既知の概念だけでは得るのが難しいような概念(自分にとって完全に馴染みのない概念)は、おそらくそもそも推論の原理的に難しくて、未知の情報に対して既知の情報が足りなさすぎて、解決への探索に計算リソースが膨大に必要になると思った。

だから、情報量が格段に多い、いわゆる難しい概念を日常的に獲得していくことで、他分野の知識も得られやすいのかなと感じた。

英語できないとつらすぎ

ハッカソンの最初で、アメリカ人の人が最近の動向とかを説明してくれていた。1時間ぐらい。最初は日本人向けに英語をゆっくり話していたけど、慣れてきたのかだんだん早くなっていき、そもそもよくわかっていないものをよくわからない単語と組み合わされて話されていたので、一部理解できても、ものすごくつらかった。

ふつうに英語の重要性を感じた。

おもったこと

最近本業でわけわかんないのにインフラ周りばかりやっていてスランプぎみだったので、集中してコーディングできて、一つのものを作り上げることができたのは、精神衛生的に良かった。

なので、こういう本業とは直接関係ない、やつあたりみたいなコーディングも時々やるのがいいかなと思った。

Spring Frameworkがどうこう以上に(たぶん個人的には使わないし)、色々と教訓が得られたのがよかった。

振り返ってみると全然大したことしてないので、たとえばDIのへんとか勉強したいと思った。

🐹

「この問題は本当に問題です」に触発されて問題作った

人に「この問題は本当に問題です」の問題が「これおもしろい。こういうの解きたい」って言われたので「じゃあ作ってあげる」ということでつくった。

いちごを5つ入れられる袋が8つあります。
その袋のうち半分にいちごを入れられるだけ入れ、
残りの袋には3つずつ入れます。
こうして作った袋をすべて入れたダンボールを1箱として、
AさんはBさんに1箱300円で6箱売りました。
Bさんが渡された箱をすべてあけてみると、
中のいちごの半分が腐っていました。
いちごの価値を1つ10円とすると、
Bさんはいくら損をしたでしょう?

けっこうめんどくさいはず

交通費のスクレイピングとかだるいのでAlfredのWorkflowとシェルスクリプトで調べるようにしてみた

はじめに

仕事中に気まぐれに読んでた記事があったので、すぐできそうだしあったら便利だなと思って、アイディアを丸パクリして実装してみました(今も仕事中)

ascii.jp

前提条件

  • Alfredがインストールされていること
  • Alfredが課金版であること

使い方

Ctrl + Space で Alfredというアプリを呼び出したあと、 eki 東京 名古屋 のようにスペースを開けて検索すると値段を表示してくれます。

f:id:haruharu1:20180807120409p:plain

f:id:haruharu1:20180807120403p:plain

作ったやつの置き場所

2018-08-07_atb6d37d | Files.fm.

これをAlfredワークフローに追加すればいけると思います(てきとう)

ここからダウンロードするの怖い人は自分で作ってください

おまけ

ワークフロー

f:id:haruharu1:20180807120759p:plain

スクリプトの中身はこんなかんじです。

query=$1

q1=$(echo "$query" | cut -d ' ' -f1)
q2=$(echo "$query" | cut -d ' ' -f2)

open "https://www.jorudan.co.jp/norikae/cgi/nori.cgi?Sok=%E6%B1%BA+%E5%AE%9A&eki1=$q1&eok1=R-&eki2=$q2&eok2=R-&eki3=&eok3=&eki4=&eok4=&eki5=&eok5=&eki6=&eok6=&rf=nr&pg=0&Dym=201808&Ddd=7&Dhh=11&Dmn=37&Cway=0&C1=0&C2=0&C3=0&C4=0&C6=2&Cmap1=&Cfp=1&Czu=2"

リファレンス

Splitting a query into two variables - Discussion & Help - Alfred App Community Forum