[読書] Apache拡張ガイド - higepon blog
Apache拡張ガイド〈上〉サーバサイドプログラミング 作者: リンカーンスタイン,ダグマクエイカーン,Lincoln Stein,Doug MacEachern,田辺茂也,田和勝出版社/メーカー: オライリー・ジャパン発売日: 2000/08メディア: 単行本 クリック: 10回この商品を含むブログ (7件) を見るApache拡張ガイド〈下〉APIリファレンス 作者: リンカーンスタイン,ダグマクエイカーン,Lincoln Stein,Doug MacEachern,田辺茂也,田和勝出版社/メーカー: オライリー・ジャパン発売日: 2000/08メディア: 単行本 クリック: 3回この商品を含むブログ (4件) を見る この本を読んで、Apacheの開発チームのセンスの良さを強く感じました。 Apacheでは、Apache APIというAPIが公開されていてApacheの全機能にアクセ
![[読書] Apache拡張ガイド - higepon blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/a9a127351fffcabfc3e161bd66d531227c7836eb/height=288;version=1;width=512/https%3A%2F%2Fimages-fe.ssl-images-amazon.com%2Fimages%2FI%2F513AK9H53SL._SL160_.jpg)
プログラマ向けに書かれた「Soft Skills」という本がすごいという話 - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
日本語版がでました。すぐ買うべし。 SOFT SKILLS ソフトウェア開発者の人生マニュアルposted with amazlet at 16.05.18ジョン・ソンメズ 日経BP社 売り上げランキング: 1,272 Amazon.co.jpで詳細を見る Soft Skills: The Software Developer's Life Manualは残念ながら日本語訳が出ていない。でも英語でも読む価値はある。とても平易な英語で書かれてる。どこかの出版社さん翻訳だして欲しい。空前のブームになるに違いない。 Soft Skills 。alc.co.jp によればソフトスキルは「対人的な交渉・指導・意思疎通などをうまく行える能力（または知恵）」のことらしい。そのタイトルからも分かる通り、プログラマ向けに書かれた本だがほとんど技術の話は書かれていない。プログラマとして生きていくための技術以外
言ったもの勝ち/言わないと伝わらない - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
今回のブログは短く。同僚・上司たちは「日本人的な空気を読む」ことはしません。というか無理。 例1 ある日の 1 on 1にて 上司「というわけでこんなプロジェクトがあるんだけどどうかな？」 僕「・・・（うわあ。これは炎上しそうなプロジェクトだな避けよう）」 僕「（困惑顔かつ拒否オーラを出しつつ）考えさせて下さい」 上司「オーケー分かった！」 翌週の 1 on 1 上司「例の件考えた？（結構乗り気だったよね？）」 僕「（いや。空気読んでくれよ・・・いやだよ）」 この場合の1つの正解は最初の 1 on 1 で率直に「ごめん。炎上しそうなのであまりやりたくないな」とか「やってもいいけど。xxx な条件なら」などとはっきり答える。 例2 上司「おい。ひげぽん。Android の仕事が入ったぞ。やってくれ。」 僕「（え。僕 iOS が好きって言ったのに・・・断りづらい）」 この場合の1つの正解は「i
マネージャとのつきあいかた - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
今の会社で 7 人のマネージャと仕事させてもらい、自分もマネージャになったこともある。その経験をふまえてマネージャとのつきあいかたを書いてみる。マネージャは日本的な「上司」と若干ニュアンスが違うので注意。上司というよりは役割の異なる同僚。 目的 マネージャとうまくつきあうことで以下を得るのが目的。 困ったときに助けてもらえる。マネージャ自身のマネージャのちから、マネージャの人脈を借りる プロジェクトの進め方、デザイン等。基本的に好きにやりたい。細かく口を出されない。 キャリアプランゴールを共有し助けてもらう 大きな 2 つの方針 初期の段階で信頼関係を築き、以降のつきあいを楽にする バランスのよい情報共有を目指すが over-communication よりにたおす マネージャの視点 マネージャの視点を意識すると何を伝えるべきかが見えてくる。マネージャがあなたについて知りたいのは プロジェ
Tech Lead（TL/テックリード）の役割 - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
Tech Lead（TL/テックリード）の役割。聞きなれない名前かもしれない。リードプログラマやテクニカルリードと呼ばれることも。過去にいくつものチーム（最大で10人以上）の Tech Lead をやってきた自分の経験を踏まえて書いてみる。 Tech Lead の主な役割 Tech Lead はエンジニア班長と言いかえるとイメージがわきやすいかもしれない 顧客に提供したい価値（プロダクトゴール）を正しく理解する エンジニアチームの生産性を可能な限り最大化。プロダクトマネージャ・デザイナと顧客に価値を提供する Product の Launch に責任を持つ Product の Launch 後のメンテナンスに責任を持つ エンジニアを過負荷から守る ときにはマネージャ、プロダクトマネージャのアイデア、スケジュールに NO を言う。代替案を提示する チーム内のテクニカルデザイン、採用技術などに責
1 on 1 で 何を話すのか？ マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
1 on 1 (ワンオンワン) とは1対1のミーティングの事。ここでは毎週もしくは隔週で行われるマネージャとその部下(direct reports)であるソフトウェアエンジニアの 1 on 1 に焦点をあてる。よく 1 on 1 で何を話したらよいか分からない。話題がない。と相談されるので僕の思うところをまとめてみる。 僕はマネージャもソフトウェアエンジニアのどちらも経験があるので両側からの視点を提供できると思う。 マネージャ編 マネージャは 1 on 1 を部下のために開催しなければならない。自分のための時間ではないことを肝に銘じよう。部下には話したいことを何でも話してもらう。事前に「1 on 1 は君のための時間だよ」と説明しておこう。 1 on 1 が始まったら「何か話したいこと、気になることある？」と問いかけよう。焦ってはいけない。じっくりと待ってみよう。 たとえマネージャとしてプ
エンジニアからみた良いプロダクトマネージャとは？ - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
エンジニアからみた良いプロダクトマネージャ（以下PM）とは。rebuildfm #98で id:naoya さん(@naoya_ito)から PM についての話があったので便乗して書いてみる。※プロダクト（製品）マネージャはプロジェクトマネージャとは全然違う職種なので注意。 結論から先に。エンジニアから見た良い PM とは「つねにユーザーのことを考えた上でプロダクトに信念を持っている人」だと思う。それは当たり前じゃないか？と思った人は正しい。でも常にそれをできる PM は多くはない。幸いにも僕は多くの優秀な PM と仕事をさせてもらったのでそこから学んだことをまとめてみよう。 PM の役割 まずは PM の役割から見ていこう。スタートアップの CEO の役割からエンジニア、デザイナーをマイナスした感じと言ったら伝わるだろうか。 もう少し具体的に PM がやっていることを挙げてみよう。 自分
Emacs で正規表現を使うなら re-builder を使おう - higepon blog
Emacs で正規表現を使うならば re-builder を使うことをおすすめします。 例えば、正規表現を良く使うシチュエーションとして置換があります。 M-x replace-regexpで置換対象文字列を正規表現で指定し、何に置換して欲しいかを指定するわけです。 行頭に // を追加してソースをコメントアウトしたいのであれば M-x replace-regexp Replace regexp: ^ ← ^ を入力 Replace regexp ^ with: // ← // を入力のように置換をします。(この場合は、comment-region が最適解ですが) 例に挙げたような簡単な正規表現であれば、間違いようもなく問題ないのですが、ちょっと複雑な置換になると話は変わります。 以下のようなコードがあるとしましょう。 byte* buf = new byte[32]; unsigned
スーパーエンジニアへの道―技術リーダーシップの人間学 を読んだ - higepon blog
スーパーエンジニアの道というと大げさだが原題は「Becoming a Technical Leader」。年齢的にもそして現ポジションもリーダーシップが必要なので読んでみた。著者はエンジニア出身でかつ、リーダーシップのセミナーを主催しているので、リーダーシップにまつわる現実的な話がたくさん。すこし冗長で読みづらかったので各章毎にマインドマップもどきを描きながら読んだ（例 これ）。 先日 id:secondlife さんにインタビューしていただいた記事 でも少し触れているのだがここ数年 Tech Lead という役割で仕事をしている。その体験と本の内容を重ねながら読み進めた。この手の本にありがちな「リーダーになるのは素晴らしい！」とか「強いリーダーになる方法！」などは一切ない。むしろ「リーダーって大変だけど。そこまでしてなりたいの？よく考えて。」とか失敗例がたくさん載っていて面白かった。某外
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
