『取締役の心得』という本を読んだら『論語』を読み出してた。 - ppworks.jp
取締役の心得 作者: 柳楽仁史出版社/メーカー: 総合法令出版発売日: 2014/07/23メディア: 単行本（ソフトカバー）この商品を含むブログを見る 最近、取締役という立場について興味を持っている。経営者とは違う、経営陣の取締役という立場についてだ。そもそも、取締役ってのは、どんな役割なんだろうだとか。執行役員って、取締役と何が違うんだろうだとか。 以前、とある会社の取締役をやった経験や、自分で立ち上げた会社の代表取締役をやった経験もあるんだけど、会社の規模感によって全然違う立場だし、偉そうなことを言うつもりはない。 子曰わく、其の位に在らざれば、其の政を謀らず。 この本を読んで、あらためて自分の経験なんて大したことないと思った部分も多かったが、ほんの少しだけ自分の行動の源泉に触れた気がした。名ばかりの経験であっても、意外とあの経験は今活きていたのだ。 取締役のように振る舞えば、取締役
pplogの「ちょっと足跡が見えちゃう」機能を偲んで( ˘ω˘) - ppworks.jp
そこには足跡があった。 そう、名前の下に「最後に読んだよしたあしあと」が出ていたのだ。正確には、「最後のあしあとの最後の20文字」が出ていた。ウッカリおしりが見えちゃっている感じだ。 何故作ったか ツイッターの名前欄にはロマンがあるんですよ。 名前欄とは、Koshikawa Naoto とか書いちゃうところである。しかし、なんでそれ名前欄に書いたのって言う文字列を名前欄に入れている人々がいるのだ。なんていうかMNS MessengerとかSkypeにあったアレ、ムードみたいなアレ。間違ってアレ目的で名前欄を書き換えている。それも頻繁に書き換えている。そんなNAMAE-RAN FREAKSがいるんですよ。 正直ツイッターにおける一番いい機能である名前欄で遊ぶという機能を、我々はそんな機能を、pplogに搭載したくなったのですよ。 （当時の会話です） そうですね、一時期「コントレックス」という
togglで、これからやることを明確にする - ppworks.jp
仕事のスピードを早めるためには、シンプルな仕事に分けてタスクを瞬殺する に限ります。 1秒もムダにしない人の 超シンプル仕事術 (アスカビジネス) 作者: 岡田充弘出版社/メーカー: 明日香出版社発売日: 2012/12/19メディア: 単行本（ソフトカバー）この商品を含むブログを見る そのためには、これからやることがシンプルで 明確である ことです。 作業開始の宣言 これからやることを明確にするためにも作業開始時に 何をやるか 宣言することが大切です。 これからやることの範囲が決まる 横道にそれない 宣言したことをやり切ることで達成感が出る 宣言することでこのような効果が得られると思います。 togglは作業時間のトラッキングツールですが、 作業開始の宣言 経過時間の確認 だけに使っています。つまり、作業宣言ツール なんですね。 経過時間の確認 togglのタイマーを見てもいいですが、私
WIPであろうと、情報共有すると何がいいのか？ - ppworks.jp
口頭で話したことを文字に起こすことについての続編のような記事です。 消え行く知見や、消え行く情報を文字にすることで永続化させ、密室の議論を無くす。その為に以下のような活動が重要という話を書きました。 口頭で相談したことをesaやqiita:teamにまとめる 口頭でコードレビューしたことをgithubやgitlabのコードレビューのコメントにも書き残す 口頭で話したことをチャットにも書き残す チャットで話しかけた後に口頭で済んだ場合、チャットに解決済と流す 情報共有すると何がいいのか？ 何がいいか。 暗黙知を減らすことが出来る 当事者に なろうと思えばなれる なろうと思えばなれるというのは、どういうことかというと、共有化された情報は、その情報をどう捉えてどう向き合うか情報を得た側が選択してこそ価値が出る。 共有された情報に対して当事者意識を持つかどうかは情報と向き合った人に委ねられるという
pplog開発のコードレビューから学ぶpull requestによる自律的行動とコミュニケーション - ppworks.jp
pplogの過去のポエムを複数単語で絞込できるようになりました。 pplogは、自身と向き合い想いを言語化するためのサイトだったりします。（色んな使い方があります） 最新のポエムだけが他人に見えますが、 自分の 過去のポエムを見る機能があります。 この過去ポエムは検索機能が付いているのですが、先日まで複数単語で絞り込むことが出来ませんでした。 pull requestが来た id: shootaさんからpull requestを頂きました。 勝手にやった！まさにこれだ！と思いました。 よし、コードレビューをしよう！ 命名に突っ込んだ これを見て思うところがありました。 search_word_arrays = params[:keyword].gsub(/ /," ").split() 私は言った for文にナニカを感じた し、Cぽい！ search_word_arrays = param
コードレビューをし合える文化がチームを強くする - ppworks.jp
コードレビューしてますか？ 「コードレビューをしよう - pblog」でも触れたのですが、 今回はコードレビューの話です。 コードレビューって何からして良いか分からなかったり、レビューアーに負担なんじゃないか、、、って尻込みしがちですが、レビューしてもらう前に気を付けること、なにをレビューしてもらうのか、そして逆にレビューするのか、そして何が起きるのかあたりを考えていきましょう。 レビューして貰う前に気を付けること レビュアーの負担を減らすのは大事です。 コーディング規約に沿っているか？といった簡単なレビューは、犬にやらせるという方法もありますが、そもそもgit-pushする前に、ローカルのgit-commit時点で対処しておくというのもありです。 犬 is rubocopですし、 rubocopやjshintなどをgit-hookにまとめて設定できるpre-commit gemが便利そう
Webサービスはヨシヨシしないとスネる - ppworks.jp
ちょっと最近構ってあげられていなかったんですね。そしたら、どうもpush通知が死んでいた模様。つまり、pplogはスネていた。 最近 pplog の通知が飛んでこなくなってしまった— ぺこちゃん (@ryopeko) 2014年10月16日 @ken_c_lo #pplog で購読してる人たちのポエム更新push通知がﾄﾄﾞｶﾅｲ疑惑— イカID: Toshiwo (@toshiwo) 2014年10月28日 ios8関連かなーと静観していたのですが、昨日ようやく本腰で調査しました。 まずは、ポエんでみる pplogは、herokuで運用しており、ログはAddonのpapertrailに流しております。なのでpapertrailを眺めながらポエんでみました（ポエむとはポエムを投稿すること）。すると、こんなログが pplog app/web.1: Too many channels (100
コードレビューをしよう - ppworks.jp
Sendagaya.rb #86 - Sendagaya.rb | Doorkeeperに参加してコードレビューについて思うところをみんなでディスカッションしたので、自分の思いをまとめておきます。（ポエム） ソニックガーデンの @mah_labさんのスライドにある7つの秘訣に同意です基本。あと、github上のプルリクでコードレビューするという前提でまとめます。 1. レビューの観点を明確に いま何の話をすべきかという状況を判断して、どの観点で物を言うのかっていうのはコードレビューだけに限らず打ち合わせ時にも大事ですね。今この観点で議論を進めますよ！ということを表明することで齟齬が防げます。 観点が明確だと議論のテーマが明確になるので、コードレビューで修正すべき点も分かりやすくなりますね。 コーディング規約の観点 セキュリティの観点 メンテンスの観点 設計の観点 リリース前にこれで出来るレ
twitter bootstrap railsを使ったら職が見つかり彼女も出来て背も3センチ伸びました。 - ppworks.jp
twitter bootstrapを更に便利に使うgemがtwitter bootstrap railsです。 railsアプリを作りましょう。 rvmでgem set作ります。 rvm --create 1.9.3-p125@tbrsample railsアプリ生成します。 gem install rails --no-ri --no-rdoc rails new tbrsample gemを指定しましょう。 Gemfileのgroup :assetsに追加します。 cd tbrsample vim Gemfile gem "twitter-bootstrap-rails" どん bundle install --without=production bootstrapをgenerateしましょう。 必要なjsやcssをapp/assets配下に配置します。 rails g bootst
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
