「技術力あげたい」という話をした - パルカワ2
speakerdeck.com 「技術力がある」とか「技術力あげたい」とかそういう話をしているが、技術力とはなにかが曖昧だと最近思っていたので自分の中の定義をプロダクト本部のLT大会で話した。 自分は10xを創る組織とはなにかに興味がありこの会社にいるのだけど、それは個人/組織が成長し続ける組織であるという仮説を自分は持っていて、プロダクト開発・運用という視点で個人の成長に必要なものとはなにかを考えたという話でもある。 もらった質問や感想など 訂正しやすくつくる力、外から中々見えにくい 見るというのはある意味評価するということだと思いますが、自分は人間が客観的に正しく人間の評価を行うのは無理*1だと思っていて、ましてや外(社外やチーム外、別職種)からはほぼ確実に無理でしょと思っています。なので中から外に説明する必要がある。 今回の話は、中*2で見えている評価をどうやって外に説明するかという
最近の本の読み方 - パルカワ2
Kindleで本を買う 読みながら、あとから読み返してもわかるように気になった箇所を黄色でハイライトする。 Glaspを使って、Kindleのハイライトとメモをコピーする Heptabaseの新規カードを作成して、コピーしたものを貼り付ける(読書カードと呼ぶ) ハイライトした箇所の章の名前を書き足していく かなりめんどくさいので、自動化したいが難しいっぽいので諦めてるがいらないような気もしてきた。Kindleアプリ上だと出てるんだけどなぁ。 読書カードにあるハイライトとメモを読み返して、自分の中で大事だなと思うところを改めて赤色でハイライトする。 Heptabaseのホワイトボードを作成して、読書カードを追加する 読書カードを右ペインに表示しながら、読書カードのハイライトとメモから大事だと思う箇所をドラッグアンドドロップで切り出してカードとして作成する。 カードを作成したら、ハイライトした
仕様書を浸透させるために仕様書のあれこれを決めた - パルカワ2
仕様書を浸透させるために何が必要か？ 品質の作り込みをしていきたい・仕様を把握するコストが高いので仕様書を書くことを会社全体で浸透させたいと思っていて、そのために書く・読むの負担軽減が重要だと考えて以下をやることにした。 仕様書の項目を減らす 仕様書フォーマットの統一 仕様書の命名規則を決める 統一されたフォーマットに沿ったテンプレートの作成 管理方法の明示化・単純化 仕様書作成・更新・廃止プロセスの明示化 仕様書の具体例の作成 仕様書を書くときに迷いそうなときに参照するガイドの作成または作成の依頼 実は一回シンプルなフォーマットを決めたのだが、自分の進め方が悪くそれが全く浸透しなかった。その反省を踏まえて上記を考えた。 仕様書の話は、このあたりの話に関係する。 仕様書は必要か？ - パルカワ2 チームが品質を作り込むために必要なこととは - パルカワ2 ちなみに仕様書は、Notionで記
ペパボを退職して、10Xに入る。 - パルカワ2
ペパボでの最終出社を終えた。 ペパボでは、大変ありがたいことにミンネ事業部のみんなや技術基盤チーム、CTLsなど優秀で人間性もいい方々に囲まれていたし、裁量もあり評価もされていたと思う。しかし辞めてしまった。 仕事はただ機能を作るだけではなく、アーキテクチャ導入に始まり、リファクタリングによる開発の効率化やアプリの高速化などといった中長期的視点による技術的挑戦も出来た。 僕がペパボに入社して少し経ったあとのふりかえりで、TRYにあんちぽさんが「ひさいちくんの技術的挑戦」を出していたけど、入社してからやってきたことをふりかえると結構TRY出来たんじゃないかと思っている。 www.instagram.com 他にもコードを書くだけではなく、2016年からはシニアエンジニアとして2017年からはチーフテクニカルリードとしてチームをどう機能させるか？技術者組織をどうしていくか？を考え、エンジニアの
tigでコミットログ見てるときに「このコミットが含まれたプルリクに飛びたい」と思うときがあるので見れるようにした - パルカワ2
@hisaichi5518 .tigrc とかで設定して、閲覧している commit をキーボードショートカットで開けるようにしておけば、commit のページに Pull Request へのリンクが含まれていそう— ホームページビルダー (@r7kamura) 2017年2月7日 ツイッターでボソっと言ったら、良い感じのアドバイスをもらったので、雑に会社のGHEだけ対応するかと思って対応した。 hub インストールして .tigrc に以下を追加して、コミットログ見てるときに shift+pを押せば、コミットページに飛ぶので、そこからプルリクへ遷移出来る。 bind generic P @sh -c 'hub browse -- commit/%(commit)'直接プルリクに遷移したいと思って頑張ろうとしたけど、複数プルリクがあるとかめんどくてこれが一番かなと思った。 追記: git
Web APIを作るときに考えること。 - パルカワ2
この記事はPepabo Advent Calendar 2014の11日目の記事です。 前日は、tnmtさんのVagrantのshell provisionerでApacheのビルド済tarボールをOSバージョン毎に作る術でした。 はじめに 今回は、Web APIを作るときに考えることをまとめました。 本当は、社内向けに資料を作っていて、社内の勉強会とかで話せればいいか〜って考えていたんですが、アドベントカレンダーのネタが本当になくて困っていたのでこれを使います。 対象者 APIを作る時、と書いてますが、クライアント側の人にとっても知っておく必要があることなので、サーバ側の人・クライアント側の人両方が対象者です。 APIを作るときに考えること 「APIを作るとき」と言っても、色んな状況があります。 まずはそれを絞ります。 APIの種類 プライベートAPI アプリのAPIなど使う人が限定され
FluentdとGoogle BigQueryで遊ぶぞ！ - パルカワ2
という入門記事を書こうと思いましたが、最高の記事があったのでやめました。 こちらを参照すると良いです。 ちなみにこういうスクリプトをピッと書いたらデータが送れてることが確認出来ました。 use strict; use warnings; use Fluent::Logger; my $logger = Fluent::Logger->new( host => '127.0.0.1', port => 24224, ); $logger->post("access.log", { uri => "http://google.com", request => { addr => "test-addr", ua => "test-ua", referrer => "test-referrer", }, }); 触った感じ便利そうなので、なんかやりたい。 これも面白い感じがします。
コードレビューをする話を新卒研修で話しました。 - パルカワ2
今いる会社には、新卒研修で座学と呼ばれるものがあって、先輩エンジニアがある程度好き勝手に話したいことを1時間ほど話す時間があります。 そんな最高の学習環境である座学で、コードレビューについて話してきました。 テーマは、 https://github.com/kenchan/keynote-theme を使いました。 内容についての補足 iOSとか出来ないので、そのあたりの説明が出来ない 最近コードレビュー全くしてない 相手によってはLGTM画像が嫌いな場合がある TPOがあるよね コンテキストが違う人にいきなりはキビシイ 海外の人にアニメ画像は使わないほうがよさそう 英語だと横向きの顔文字とかよく見る ;P 美女LGTM画像は会社で使ったことない スライド作る時に気をつけたこと 6個のステップ、3つの目的とか個数を言うようにした。 新卒氏たちに今やるべき事を認識してもらう 新卒氏たちにも出
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
