生産性を支える技術、ポモドーロテクニック

ポモドーロテクニックを知っていますか?
マイナーなものではないので、知っている方も多いとは思いますが、
ここ最近仕事を行う上で、ポモドーロテクニックを取り入れたので、
ポモドーロテクニックとは何かというところから、
ポモドーロテクニックを行う上で心がけておくべきことをお話しようと思います

※以下は僕個人の意見です。自分や自身の仕事に合わせて適用させるものだということを忘れないでください!

ポモドーロテクニックとは?

生産性を上げるためのメソッドで、短時間でフォーカスした作業と休憩を繰り返すものです
ルールは簡単です
まずタイマーを用意しましょう(検索すればアプリ等も見つかるはずです)
一般的には25分間作業し、その後5分間休憩します
それを1ポモドーロ(以下ポモドーロ🍅)と設定し、4ポモドーロ🍅毎に15分間休憩します
また、作業中に割り込みタスクが入った場合、そのポモドーロ🍅はfailしやり直します

これだけです。ただこれが結構強力なんです

良いところ

集中する

ある一つのタスクだけにフォーカスするため、集中力が増します
また、割り込みが入るとそのポモドーロ🍅がfailするという特性上、割り込みをできるだけ削減することに必然的に努力します
これが更に生産性を高めます
もちろん集中するので一日で8ポモドーロ🍅くらい集めた時点から疲労を感じるのですが、
僕はポモドーロテクニックを適用した場合は、気持ちいい疲れとして疲労を感じます

休憩を取る

みなさんも経験があるかもしれませんが、作業中に休憩を取ることを忘れるということがあります
それは、その後の疲労感や作業効率のことを考えると必ずしも良いこととは言えません
ポモドーロテクニックを利用してコンスタントに短めの休憩を取ることで、リフレッシュすることができます

指標になる

いくつポモドーロ🍅を集めるか、いくつ集められたかということを考えることができるということに加え、
タスクの工数を考える点でポモドーロ🍅を利用することができます
また、ポモドーロ🍅毎に振り返りを行うこともできます

注意点

ポモドーロテクニックを実施するにあたって注意すべき点を列挙します
これは自分自身にも投げかけるものです

自分に最適な間隔か?

25分、5分、15分、4回に1回などの規定された時間に囚われるのは駄目で、自分に最適な数値を見つけましょう
もちろん規定に従うほうが楽という場合はそれで問題ないです

休憩中に作業してないか?

休憩がポモドーロテクニックに於いてコアとなる部分だと僕は思っています
ディスプレイを見ない等、はっきりとルールを決めておくことが大切です

タスクを定義しているか?

ポモドーロテクニックはある一つの作業に集中するということを手助けしてくれるメソッドです
そのためタスクを定義していないということは大問題です
1ポモドーロ🍅で終了しないタスクは、1ポモドーロ🍅で達成できる粒度にタスクを分割します
また、1ポモドーロ🍅もかからないタスクは同じように小さなタスクを集めて、それを1ポモドーロ🍅の作業とします

自分に合っているか?

これが一番大切です
自分の性格や、自分の仕事にこのテクニックが合っているかということです
同時に複数のタスクをこなさないといけない人や割り込みタスクが多い人には向かないでしょう
しかし、実は割り込みタスクは後回しにすることが可能かもしれません
一度、自分に当てはめて考えてみましょう

まとめ

単純だけど面白いテクニックだと思いませんか?
始めたばかりで、まだまだ改善すべきところがあると思うので、どんどん更新してみようと思っています
明日もポモドーロ🍅集めがんばります!

Semicolonless Java 入門

これは coins Advent Calendar 11日目の記事です。

10日目の記事は 自炊しろITF.生 - 気合でなんとか です。
外食も最高なんですが、自炊の良いところはたまにありえん美味しいものが出来上がってしまうことがあるということですね。
多分自炊してる人は経験あると思います。でも、味付け難しい。

空いてたので2記事目を書くことにしました。

ところで、あなたはJavaでは絶対セミコロンを書かなければいけないと思っていませんか?

しかしそんな必要はありません。

今日は あなたにSemicolonless Javaの世界を紹介します。

Semicolonless Javaのルール

セミコロンを用いてはいけない
ユニコードエスケープは不可
Java SEの標準APIだけを使う
Semicolonless Java 2012 - プログラマーの脳みそ

簡単ですね。

Hello, World!

Java8時代のSemicolonless JavaでHello, World!を実行するには幾つか方法がありますが、今回は2つ紹介します。

if (java.util.concurrent.Executors.callable(() -> System.out.println("Hello, World!")).call() == null) {}
1つ目

1つ目はif文と java.util.concurent.Executors.callable の合わせ技です。

if文の条件式の中でメソッドを呼び出し、その戻り値と何らかの値とを比較する手法はSemicolonless Javaでは昔から使われている定番的な手法です。

しかし、 java.io.PrintStream#println の戻り値は void なため、何らかの値と比較できず、この手法は利用できません。

そこで、Executors.callable の出番です。 callable に Hello, World! を標準出力に出力する Runnable を渡して Callable<Object> オブジェクトを生成し、 Callable#call で渡した Runnable を実行します。

Callable#callRunnable の実行後にその結果を自身のオブジェクトの型パラメータで返します。ここでは Callable の型パラメータは Object なので戻り値は Object 型のオブジェクトとなりますが、 Executors.callable の戻り値 Callable オブジェクトは null を返す実装になっています。

2つ目
try (java.util.stream.Stream s = Stream.of().onClose(() -> System.out.println("Hello, World!"))) {}

2つ目は try-with-resources 文と BaseStream#onClose の合わせ技です。

try-with-resources 文は、宣言したリソース( AutoClosable を実装しているクラスのオブジェクト)をtry文が終了したら自動で閉じる、つまり AutoClosable#close を呼び出すというものです。

Streamスーパークラスである BaseStreamAutoClosable を実装していて、 BaseStream#close が呼び出された時に、 BaseStream#onClose で引き渡した Runnable を実行します。

変数宣言

Java8以前のSemicolonless Javaでは変数宣言に拡張for文が用いられていましたが、Java8では StreamStream#peek の合わせ技を用いることがあります。

if (Stream.of("James").peek(firstName -> Stream.of("Gosling").forEach(lastName -> System.out.println(firstName + " " + lastName))).toArray() == null ) {}

まず、何らかの方法で宣言したい変数の値を持つ、一つしか値を持たないStreamを作ります。 Stream.of を利用すると簡単に Stream が作れますね。

さて、この Stream に対して Stream#forEach を呼んで、その中で変数を利用したいところですが、 Stream#forEach の戻り値は void です。前述のvoidを回避する手法を用いても良いのですが、今回は Stream#peek を使います。

Stream#peekStream をそのまま返しますが、 Stream の各要素に対して、引数として渡した非干渉アクションを実行します。主にデバッグ用途で利用されますが、今回はこれを悪用利用しました。

ところでラムダ式では文をブロックを用いず1行だけ書く場合に限り、セミコロンを省略することができます。つまり、その中では任意のメソッドを呼ぶことができるわけです。今回はもう一つ変数を宣言して、 Stream#forEach でこれら2つの変数を利用しています。

Fizz Buzz

さて、入門記事ということで、Fizz Buzz*1までやりましょう。

 if (java.util.stream.IntStream.rangeClosed(0, 100)
    .mapToObj(n -> n % 15 == 0 ? "FizzBuzz" : n % 3 == 0 ? "Fizz" : n % 5 == 0 ? "Buzz" : String.valueOf(n))
    .peek(System.out::println)
    .toArray() == null) {
}

まず、 IntStream.rangeClosed で0から100までの Integer 型の Stream を生成します。

次に、 Stream#mapToObj を利用して、その各要素を3項演算子を用い、適切な String オブジェクトに変換します。

そして、 Stream#peek を呼び出して標準出力に出力し、最後に先述した手法を用いてセミコロンを排除しコードを実行します。

簡単ですね。

Java 8になってからSemicolonless Javaがとても簡単になってしまいました。なので、Java 7以下縛りとか、どんどん縛りをきつくしていくと良いと思います。

参考までに、昔Java 7でSemicolonless Java入門したときのコードを貼っておきます。

縦書き俳句プログラミング in Semicolonless Java. · GitHub

Java 9時代のSemicolonless Java

$ jshell
jshell> System.out.println("Hello, World!")
Hello, World!

なんでや!

参考

筑波大学周辺のアパート事情

これは coins Advent Calendar 7日目の記事です。
6日目の記事は @ITF_sudame による http://sudame.net/blog/20171206 です。
エラーをよく読むことは大切ですね。

さて、本題に入りましょう。
一般的な物件選びに必要な知識は、インターネットの海にあふれているのでそちらを参考にしてもらうとして、今回は筑波大学周辺に限った事について書きたいと思います。
あと、この記事の内容は体裁を整えて、来年度の新歓パンフに載せる予定です。

宿舎と比較した一般的なアパートのメリット・デメリット

メリット
  • 部屋が広い
  • 自由風呂、自由トイレ、自由キッチン、自由洗濯機がある
  • 好きな場所に住める
  • お湯が出る
デメリット
  • 家賃・光熱費が高い
  • 隣人との関わりは殆ど無い

宿舎に住んでいる人から宿舎はお湯が出ないと聞いたときは腰を抜かしました。お湯は人権。そう思ってた頃も僕にはありました。

大学生の街、つくば

ここは大学周辺です。言わずもがな大学生が夜中に集まります。というわけで、部屋を隔てる壁は厚いに越したことはありません。とはいえ現実問題、隣人ガチャでSレアを引くことができるかなので、アパートに引っ越すことを考えている場合は徳を高めておきましょう。

つくば特有で必要なもの

つくばの水道水はとても美味しいとは言えない代物なので、浄水器を設置することを推奨します。

家賃、そしてどこに住むか

一般的に、つくばは他の地域と比べ家賃が安いと言われています。

地区 家賃の安さ 飲食店の多さ 3学*1との近さ 駅との近さ スーパーとの近さ
天久保2丁目 ★★★★ ★★★★ ★☆☆☆ ★★★★ ★☆☆☆
天久保3丁目 ★★☆☆ ★★★★ ★★★★ ★★☆☆ ★★☆☆
天久保4丁目 ★★★☆ ★★☆☆ ★★★☆ ★★☆☆ ★★★☆
春日3丁目 ★★★★ ★☆☆☆ ★☆☆☆ ★★★★ ★★☆☆
春日4丁目 ★★★☆ ★☆☆☆ ★★☆☆ ★★★☆ ★★☆☆
★☆☆☆ ★★★★ ★★★☆ ★☆☆☆ ★★★★

ランク付けに関しては、独自調査の結果*2及び、友人の意見を反映させたもののため、参考程度にお願いします。

まとめ

アパート・マンションはいいぞ。

コン応のツイートチェッカーを書いた

http://conapp.yuiki.jp/

経緯

コンテンツ応用論2017 というハッシュタグを付けたツイートを30ツイート(諸説あり)して、出席とみなされるという謎講義がある

30ツイートとか楽勝だろうと思っていたら

60人落単はやばい

やばいと思ってたら、公式から先述のスクリプトが公開された
謎のやる気が出てきたので、昨日家に帰ってから誰でもWebから確認できるようにコードを書いて、適当にデプロイした
何も考えたくなかったのでAWS EC2+Nginx+Gunicorn+Django+bootstrap 3+Tweepy+Social Djangoという構成
EC2, Gunicorn, Django, Social Djangoは初めて使ったけど、知見が溜まっていたのでサクッと作れた

先ほど、Githubに上げたので良ければContribute欲しいです

github.com

特にこれをなんとかしたい
/checkの結果を非同期で返す · Issue #2 · Yuiki/conapp_checker · GitHub

追記

コン応用ツイートスクリプト
#コンテンツ応用論2017 で30ツイートつぶやくやつ · GitHub

コン応用ツイート監視スクリプト
#コンテンツ応用論2017 のTweetを追う · GitHub

ロードバイクで峠を下っている途中、バーストしてロードサービスを利用した話

言いたいことは、ロードサービスに入る意義はあるぞ。 ということで、以下はただの日記みたいなものです。

ロードバイクで、峠を下っている途中、「バァン!」と、大きな音が鳴り、空気が抜けたのでチューブを交換したんですが、またすぐにパンクしてしまって、よく見てみるとタイヤがバーストしていました。

初パンク、初バースト。

とは言っても電波も繋がらないような森の中、どうすることもできず、とりあえず新しいチューブに少しだけ空気を入れて、峠を更にゆっくりと下って行ってたんですが、再度パンクしてしまいました。

参った。

しかし、約二週間前にロードサービスに入ったことを思い出しました。
どうやら年四回まで50km以内なら無料で自転車を運んでくれるようです。

少し峠を下ったおかげか、電波がつながる場所に来ていたので、専用のアプリをダウンロードして、ロードサービスの要請をします。

10分位待った後でしょうか?
知らない市外局番(どうやら秋田らしい)から電話がかかってきて、名前や、簡単な現在位置の確認、車体の色、スタンドがついているかどうか、同乗者は運んでほしいかなどを聞かれました。
このロードサービスは自転車を運ぶ、というものであり、人を運ぶのは保険対象外のため、もし事故等があっても責任は取らないという旨を言われました。 もちろん運んでもらうと即答します。
そして業者を手配するのでまた掛け直すと言われ、電話が切れました。
この保険は、全国各地のいろいろな業者と契約しているようで、その業者を探すのに時間がかかるということです。

Twitterを見たりするなどして、15分位時間をつぶしていたところ、再度電話がかかってきました。
先程とは違う人でしたが、業者の手配が終わったという連絡がありました。
しかし、今日は営業日云々いわれ(土曜日でした)、業者が来るまで40-50分かかると言われました。
しかし断る理由はありません。自宅まで歩くとなると何時間かかるのやら…。

とりあえず待つことにしたんですが、次第に雨が強くなっていき、土砂降りになりました。 幸運なことに雨具を所有していたので、それを着て業者からの連絡を待ちました。

業者から連絡がありました。今向かっているので、後30-40分待ってくださいというものでした。

辛い。

しかし、土曜日でしかも山麓。これは仕方ない。
おとなしく雨の中、自転車の様子を確認するなどして30分程待ちました。

すると業者がやってきて、丁寧に自転車を車の中に運んでくれました。
ロードサービスに関する誓約書にサイン等します。
そして、同乗させてもらい、自宅まで自転車も僕も運んでもらいます。
このドライバーの方が本当に優しくて、度々寒くないか?とか、喉乾いてないか?とか聞いてくれます。
他愛も無い話をしつつ、とりあえず家にたどり着くことができました。

チューブ3本死ぬわ、タイヤもお亡くなりになって、ランもリアイアで良いことなかったんですが、ロードサービスに入ってて良かったと切実に思いました。これでロードサービス入ってなかったらどうなったことか。考えたくもないです。

とりあえず先程自転車のメンテを済ませて、タイヤをAmazonでポチりました。明日の夜はタイヤ換装かな。