質問：マネジャーを続けるかエンジニアに戻るかで葛藤しています
チームのリーダーとしてマネジメントを任されるようになりました。自分としては一エンジニアとして頑張りたいという思いもあり、このままマネジャーを続けるかエンジニアに戻るかで葛藤しています。藤本さんのご意見をいただければ幸いです。 まず最初に大事なことは、いわゆるチームマネジメントは決して片手間でできるようなものでも、やっていいものでもない、ということです。なので、結論を先に書いてしまうと、葛藤している暇があったら早めにどちらか決めてしまいましょう。まぁ言うのは簡単なんですけどね。 ものすごく単純な例えですが、エンジニアとして10台のサーバーで一つのタスクを分散処理したり一つのシステムを動かしたりするのと、マネジャーとして10人のチームメンバーを一つのゴールに向かってまとめ上げて走り続けることの、どちらが簡単でしょうか？ 前者を簡単と言うつもりは全くありませんが（前者も十分に難しいことが多いので
ITエンジニアの幸せな未来とは？ - さくらインターネット創業日記
Something went wrong, but don’t fret — let’s give it another shot.
技術選択とアーキテクトの役割
特定のプロジェクトがあり、要件定義をし概要設計をする。 それがアーキテクトの仕事だと思われがちですが、大きな視点を持ち様々な課題を自らリードして解決していく立場としても絶好のポジションです。 このセッションでは、Mobage オープンプラットフォームの立ち上げから、 グローバルプラットフォーム展開、さらには mixi 社との共同プラットフォーム構築、 JavaScript SDK と認証技術の組み合わせによる新しい HTML5 プラットフォーム構築をアーキテクトという立場でリードし続けた立場から、技術選択のみならず実現したい事に対する俯瞰的な捉え方を、これまでの実例と共に紹介し、アーキテクトという役割について、お話します。
クラウドワークス勉強会「レガシーコード改善の戦略と戦術」（前篇：戦略） - CrowdWorks Engineer Blog
こんにちは！年初からクラウドワークス開発に新たにジョインした所と申します。 先日、クラウドワークスではテスト駆動開発とRESTFulアーキテクチャのエバンジェリストとして有名な和田卓人さんをお招きして社内勉強会を開催いたしました。 和田さんは、数多くの会社にてレガシーコード改善のコンサルティングの経験をお持ちで、書籍も多数執筆されており界隈でも有名な方です。 また、弊社CTO大場の旧知の友人でもあります。 クラウドワークスのサービスは立ち上げから現在に至るまでRuby on Railsで開発を行っており、サービス拡大に伴いアプリケーションの規模も大きくなっています。 比較的テストが書きやすいフレームワークではあるものの、ビジネスの急激な成長を支えるために速度を優先した機能開発が行われていた時期もあり、レガシーコードが残っている部分があります。 将来に向けて技術的負債の返済をしていくことは、
Reddit - Dive into anything
There are two things I immediately don't like: HTML directly mixed in your JS mixes the presentation layer with your logic, breaking separation of concerns. .JSX files - It's built around the concept of compiling your JS files, which to me seems like a framework overstepping its bounds. These two things strike me as something that would quickly send a UI framework down the drain, so I can't help b
チームメンバーとの信頼関係を築く：定期個人面談の薦め - クックパッド開発者ブログ
こんにちは。新規広告開発部所属エンジニアのレオ（@lchin）です。 ここ2年ほどは、大きな事業部のなかの小規模なエンジニアチームのリーダーを務めてきました。エンジニアリーダーとしては、1人のエンジニアとしてソフトウェア開発をしつつ、チームのメンバーの力をまとめて、事業部のゴールを推進しました。事業部のマネージャほど、マネジメント業務が中心になるわけではありませんが、多くのエンジニアが苦手な人間関係スキルはエンジニアリーダーにも必要です。 メンバーは何か大きな不安を抱えていないのか？ポテンシャルを発揮できていないメンバーにどうフィードバックするのか？メンバー間に何かトラブルはないのか？見えないところで仕事の妨げはないか？チームでソフトウェア開発を行う上のよくある悩みだと思いますが、皆さんはどう解決していますか？私は、個人面談はこういった悩みを解消するための大変有効な手段だと思います。 なぜ
VOYAGE GROUP エンジニアブログ : 今、クライアントサイドのJavaScriptを書く前に知っておきたいこと ~ 2014年トレンド総まとめ
2015年02月05日16:34 カテゴリ 今、クライアントサイドのJavaScriptを書く前に知っておきたいこと ~ 2014年トレンド総まとめ 皆さんこんにちは。adingoにてFluctという広告配信システムの管理画面を中心にクライアントサイドの開発を行っております、大関です。 今回は、先日、社内のエンジニア向けに開催した「2014年のJavaScriptのトレンド総まとめ」というコンセプトの勉強会の内容について紹介します。 JavaScriptトレンド総括（2014） from Tetsuharu OHZEKI それでは、スライドに書ききれなかった前提事項について、何点か補足と解説をします。 補足と解説 前提: なぜ「2014年」なのか JavaScriptを用いた開発、特にWebフロントエンドとも呼称されるクライアントサイドJSのトレンドは、非常に速いサイクルでの進化を見せて
ssig33.com - よく分からない人のためのセキュリティ
いろいろと原則論はあるんですが。昨今のアプリケーションは複雑化し、扱う情報はよりセンシティブになり、そしてより幅広く使われるようになっています。よって「安全な」アプリケーションを作るために必要な知識はますます増える傾向にあります。 よく分かってない人は以下のことにとりあえず気をつけましょう 1. なるべく自分で作らない これは最も重要なことです。検索する、他人に聞く、自分で考えない。これは重要です。大抵の問題は他人が作ってくれた解決策を適用できます。 例えばセキュアな問合せフォームを作ることにしましょう。気をつけるべきことは以下のことぐらいでしょうか。 送信内容の確認画面を表示する場合、ユーザーの入力した値は適切にエスケープするように 送信内容をアプリケーションの DB に格納する場合には SQL インジェクションを防がなければならないので、プリペアドステートメントを用いる CSRF 対策
君にグロースハックはいらない
2015 年 1 月 30 日に Viling Venture Partners で行ったグロースハックに関する講演資料です。 『君にグロースハックはいらない』というタイトルは別にグロースハックを dis っているわけではなく、いずれ必要になる方法がまとまっていると思います。ただ 74% のスタートアップの死因が premature-scaling という報告もあるように、あまり初期においてスタートアップが (細かなテクニックなどを中心に膾炙してしまっている) グロースハックの手法に力を入れてスケールしてしまうと、意味がないどころか自分の首を絞めるだけなのでは、という考え方を中心にまとめています。
Groovy project should have a clear governance structure
I just came back from Tokyo to learn that the Groovy project is looking for a new home. Related posts from the project leaders here, here, and here. Hacker News commentary is here. This news hit close to home for me for several reasons. For one, I like Groovy a lot myself, to the point that I have developed several projects around it (like this and this.) Two, the Jenkins project uses Groovy a lot
テストの自動化を考える前に
5. 前職で実際にあった出来事 マネージャ 今回はテストファーストでやります ぐるぐる はい！ マネージャ なので、実装に入る前に テスト仕様書を完成させます ぐるぐる はい？ マネージャ テスト仕様書は実装開始までに Fix され、以降の変更は認めません ぐるぐる はいぃぃぃぃ？
CTOの役割と組織における技術的ポートフォリオの組み方 - Hatena Developer Blog
はてなCTOのid:stanakaです。 はてなアドベントカレンダー2014も最終日となりました。 今年のアドベントカレンダーは、スマートフォンアプリ開発からシステム系論文の話まで幅広いテーマが集りました。 読んでいて優秀なエンジニアがいるなぁ、としみじみ思います。 ちなみにアドベントカレンダーは25日までじゃないのか、という話がありそうですが、本来は24日までだそうです*1。 CTOとは何か論 最終日の今日は「CTOの役割と組織における技術的ポートフォリオの組み方」について考えているところを書いてみます。 最近、なぜかCTO論が盛んで、あちこちでよく耳にするようになってきています。 rebuild.fmでのnaoyaさんのマネージメント話や、WEB+DB Pressの舘野さんの連載などでもCTOやエンジニアのキャリアについての話が盛り上がっています。 つい先日でたWEB+DB Press
ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか？もしくはコードカバレッジだけにとらわれすぎていないでしょうか？ 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
Fluxとはなんだったのか + misc at 2014 - saneyuki_s log
はじめに VirtualDom - なぜ仮想DOMという概念が俺達の魂を震えさせるのか - Qiita を読んでいる前提で話を進めます。 結局”Flux”なんだったのよ 詳細については過去に自分が覚え書きを書いたのでそっちを読んでいただけると良いと思うけど、あれは 「MVCの変形亜種に、オブザーバーパターンを乗せ、データを単一方向に流すことを規定した」ものに、Facebookが命名したものでしかない。極端に目新しいものでもない。その最大の功績はアーキテクチャそのものではなく、「試行錯誤を踏む中で誰もが一度はやっていたであろう似たようなことを上手く実践法則としてまとめた上で、共通認識としての名前をつけた」こと。概念に名前をつけて共有することで、事前説明が簡略化され、本質的な問題に取り組む時間が増える。これをFacebookのブランド力でねじ伏せるように広めたことこそが重要かつ評価すべきポイン
チームでSymfony2を半年使って感じたメリット・デメリット[PHP][Symfony2] - あざらし備忘録。
この記事はSymfony Advent Calendar 2014 19日目の記事です。 はじめに 今年新卒として配属されてからエンジニア4人のチームで半年ほどSymfony2を使って開発をしてきて、Symfony2で良かった(メリット)と感じた所や、こういう時辛いねー(デメリット)と感じた所がいくつか見えてきたので、まとめようと思います！ 使おうかどうか迷っている人などの参考になればと思います。 メリット まずはメリットから。良い所がたくさんありました！ 部品の再利用性が高い Symfony2は本当に疎結合に徹底した思想だなと感じました。 Symfony2はいわゆる「フルスタックフレームワーク」のイメージが強いですが、その他のプロダクトにもぶちこめるほどのパーツ単位のものが組み合わさってフルスタックな形を実現しています。 なので、そういったSymfony2が提供しているコンポーネントのご
![チームでSymfony2を半年使って感じたメリット・デメリット[PHP][Symfony2] - あざらし備忘録。](https://cdn-ak-scissors.b.st-hatena.com/image/square/068a70e88853861f37694796ec2dde944de7bd0b/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F12704830469095606045%2F8454420450077406189%2F1418956904)
エンジニアの評価観点について - @katzchang.gist
techass.md エンジニアの評価観点について こんにちは。 @katzchangです。 VOYAGE GROUPでは人事評価制度の一つとして技術力評価会というのが年に2回ほど開催されて、半年くらいの仕事から何かテーマをピックアップしつつ、別チームのエンジニア2名とお話をしつつ、なんと評価までされてしまうという、とても楽しい会があります。 評価する側のエンジニアも多様で、ある程度の評価軸はありつつも、それぞれの質問や評価はそれなりに個性が出るものだろうなーと眺めています。ということで、私なりの質問や評価のポイントをいくつか挙げてみます。 質問に対して明確に答えるための手段を知っているか？ 例えば「キャッシュの有効時間はどれくらいか？」みたいな質問をすることがあるとします。当然、「わかりません！」で終わると残念なのは皆知ってるので、頑張って答えようとします。しかし、その場で「xx分です！
楽天 TechTalk で Ruby と Rails の話をしてきた, 技術的負債を返却するには何をすればいいか - HsbtDiary(2014-12-12)
■ 楽天 TechTalk で Ruby と Rails の話をしてきた 楽天の河口さんから Ruby と Rails を使ってビジネスを回しているという話をしてくれという依頼がきたので、2日前の 12/10 に楽天オフィスまで言って何か話してきた。当日は遅刻してしまって申し訳ありませんでした...品川シーサイド難しい... 話の内容は、今年の RubyConf Taiwan と RailsPacific で話した内容を足して2で割ったような内容を1時間弱という感じ。 散々聞いた話だと思うけど 使い捨てじゃないプロジェクトやサービスで Rails 使うなら継続的にバージョンアップして技術的負債を返し続けるのが良い。一気にビッグジャンプしようとするととてもコストがかかるし、そもそも出来るかどうかわからない。 Rails 使うなら、Rails が良いとしているテクノロジーや方向性に積極的に乗っ
Goに入ってはGoに従え
Goに入ってはGoに従え Go Conference 2014 autumn 30 November 2014 鵜飼文敏 Fumitoshi Ukai Google Software Engineer - Chrome Infra team Go Readability Approver Go言語のReadabilityをレビューするチーム コードレビューを通じてGo言語のよいコードの書きかたを教える メインのプロジェクトとは別のコードをレビュー 一年前くらい前に参加して 20% timeで 200くらいのCLをレビューしました 今は一日3CLくらい、週に12CLほどのペースでやっています Gopher by Renée French 2 Readabilityスキルとは? プログラミング言語のリテラシー 作法にかなったやりかた で、読んだり書いたりできる能力 言語ごとに作法が違う C++
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
“I wrote some code. I think you should maintain it.”
O/Rマッパーによるトラブルを未然に防ぐ
