Code for Okinawa Meetup #1 を10月25日に開催します
Code for Okinawa Meetup #1 : ATND
特に何をするということを決めていないですが、定期開催としてやっていきたいと思って、思いつきで立てた。
順次コンテンツが決まり次第、周知していきます。
思いつきで始めたので、とりあえず参加ぐらいな感じの意気込みがちょうどいいかと思います。
ギークハウス沖縄で僕と握手!!!!
annictのコードリーディング(5)
つづき。なんとくなーくRailsでのAngularJSの使い方がわかったような気になってしまったので、なんかただ読んでるだけって感じになっているんですが…orz
以下メモ
upstream masterした
管理画面とかしっかり作ってるのすごい
- というか作ってるのが当たり前なのかもしれない…
-
.yesterday
とかbetween_times
とかの時間区切りで取得するっていうやつ?可読性高くなりそうだなー。
Controllerの前に
permits :name
とかそういう感じの表示があるparams[:hoge].permit(:name) とかじゃないの?
asakusarb/action_args の仕業だった。
- これは綺麗に書けるなぁー。最初は面食らったけど。使ってみよ。
devise_for :skip
っていう表記。なんだろこれ。Method: ActionDispatch::Routing::Mapper#devise_for — Documentation for plataformatec/devise (master)
Deviseが提供している機能を省きたいときに使うのかな?
今回読んでるとこだと、registrationか。
- あーDeviseが提供しているものではなく、自分で実装したものを使ってるんだ。
Keen.io に ログインしたっていう情報を渡しているんだねー。
How To: Allow users to edit their password · plataformatec/devise Wiki
by_passっていうのがあるんか…
- あーDeviseが提供しているものではなく、自分で実装したものを使ってるんだ。
annictのコードリーディング(4)
つづき。だいぶ間があいてしまった。。。 なんかgemの紹介になっているけど、とても参考になる。
メモ
app/models/work.rb
has_paper_trail とは
noneってなんだろう
空のオブジェクトを取得かー。
recommends
Pomotodoが良かった。
Pomotodoを使い始めた(正確に一度やめていて、はまた使ってみた)。
仕事の生産性をグラフで美しく統計化できるアプリ『Pomotodo』 | ライフハッカー[日本版]
良い所
ポモドーロをスタートした時間とかを計測してくれて、一日、一週間どれくらいだったのかってのをグラフィカルでいい。
何曜日の何時ごろが一番効率的かってのを見せてくれる。
一日の振り返りが簡単にできる。
Chromeエクステンションがいい。
名前が「ポモトド」ってのがかわいい。
ポモドーロ中の間、StayFocusdみたく、特定のサイトの閲覧をブロックできる。(休憩中は閲覧できる)
こうなればいいなってところ
- 15分の休憩がないので、そこを入れてほしいなぁ
ポモドーロテクニック系のアプリは何度もインストールとアンインストールを繰り返しているのでまたやめるかもしれないけど、なんか欲しい機能を網羅してくれていいなぁと思ったので、しばらく続けてみる。
ZERO to ONEを読んだ
- 作者: ピーター・ティール,ブレイク・マスターズ,瀧本哲史,関美和
- 出版社/メーカー: NHK出版
- 発売日: 2014/09/25
- メディア: 単行本
- この商品を含むブログ (1件) を見る
競争は良くないとか、隠れた真実を見つけて、それはなるべく限られた人に共有するようにした方がいいよだった。
【第25回】間違っているのは、文系よりも理系的態度かもしれない。|川上量生の胸のうち|川上量生|cakes(ケイクス)
なんとなく似てるなぁと思った。
印象的だったのは、「あいまい」の表現から出てくる、環境エネルギーと社会起業っていう話。
ふわっとしすぎてるんだよ!みたいな感じだったと思う。
この本は、リーンとかそういうのと正反対で〜とか言うのを見たけど、あんまりそんなこと言ってる感じじゃないなぁと思った。
それはあくまでも手段であって、目的じゃないよ程度の抑え方な気がする。
読みが甘いのかもしれないし、読んだのに早速忘れてきているところもある。
また時間があったらちょこっと手を取るのかもしれない。
目的と手段、履き違えないようにしたいなぁ。
自分の現状の問題
コードが汚い。
コードリーディングをもっとした方が。
というかコードもっと書けよ論もあるね。
そういった関連書籍を読むとか。
読むだけで実践になる?
アウトプットもセットで。
ブログとか?
- 引用祭りになりがち。
情報に振り回されすぎ
まとまった集中時間を確保するために - yaotti's diaryでのPocketの方法は良さそう。
メールを落とすってのもいいかも
学習時間が少ない
- 学習したい項目が多すぎる?
時間の見積もりが甘い
- アジャイルな〜から学ぶ
金額の見積もりが甘い
- アジャイルな〜から学ぶ
スケジュールの組み方
- 紙でタスク書いて消していくやつ、とても良かった。
基本的な時間的な問題は、多分計測していかないとわからないことだから、明日以降はポモドーロしていく。
「行動観察の基本」を読んだ
デザイン思考とか、サービスデザイン系統の話だった。
実際にどういう手段があるかってのは、
サービスデザインシンキングが詳しい。
基本的に、場で起こっていることに注力していくことが重要っていう話で、それはインタビューとかでは出てこなくて、
その人の生活まで入り込んでいくべきだよとかそういう感じの話をしていたと思う。
話の中で、「オープンイノベーション」というキーワードが出ていたけども、
僕が学生時代にこれをテーマにちょっとした論文みたいなものを書いたことがあって、
その頃には日本語の文献も多かったので、あんまり新鮮味はなかった。
(まだそういった話が有効であるぐらい、強力であるっていうことなのかもしれないけど…)
仮設を導き出すために、行動に対して興味や共感を持って謙虚に接し、幅広い知識を持って、枠を再構築していきましょうっていう話。
実例を3つぐらい紹介しているので、そういった実例が出てきた中で、一体どういった仮説を導き出したのかってを知れるところは良かった。
ここからは個人的な話。
関係ない話かもしれないけど、読んでいく中で、そういった仮説を組み立てるための「幅広い知識」を得るためには
やっぱり1人のちからでは足りなくて、なんというか、そういったことを共有できる「たまり場」を構築してみたいなぁなんてのを思いました。
あと、今関わっている方たちは、皆オフラインに近いというか、現場を知った上での課題解決を思いついているので、できればもっとそっちの方に注力してもらって、
自分たちが、じゃあその課題をどうやって解決していくのかって部分に注力していくことが必要だなと感じた。
そのためにも今の自分の知識量や技術力ではまだ太刀打ち出来ない部分が多いので、
自分の課題としてはそこだなぁ