新しくプロダクト開発に入ったときにやっていること | wapa5pow blog
年度が代わり新しい環境に行く人も多いですね。新しい環境・プロダクトだといろいろ戸惑うことがあります。自分は数年ごとに転職し、副業も複数のところでしているので初めての環境に関わることが結構あります。そのなかで素早くチームになじんでプロダクトに貢献できるようにやっていることがあるのでそれを紹介したいと思います。 自分がウェブやアプリのエンジニアなのでその文脈で話します。 「プロダクトのあるべき姿と現状を把握する」と「短期的・長期的に貢献できることを探す」ことを意識してやっています。 プロダクトのあるべき姿と現状を把握する 関わるプロダクトがユーザの何を解決しているのか理解することは開発する上で非常に大切です。機能を開発する上でもただ開発するだけでなくその機能自体が必要なのかどうか、必要ならどのような機能にすればユーザが問題を解決しやすいかという何を開発するかに密接にかかわっています。 1. ア
技術的負債の返済プロジェクトが失敗する 11 のワケ - jfluteの日記
ワケ一覧 序の口: フレームワークだけが負債だと思ってる 序二段: ビジネスサイドに理解してもらう努力がない 三段目: 技術で遊び過ぎてしまう 幕下: 太り過ぎアーキテクチャ 十両: 過去に目もくれず、現状だって見ない 前頭: 技術に詳しいだけでアーキテクト 小結: アーキテクトの知識と覚悟が足りない 関脇: スパンが長く、モチベーションが続かない かど番大関: スパンが長く、人の入れ替えでチグハグ 大関: アーキテクチャデザインはどこへ？ 横綱: 実は人間的負債だった 序の口: フレームワークだけが負債だと思ってる みんな、フレームワークが大好き。とはいえ、さすがにみんな、「フレームワークが古いことだけが負債」だなんて思ってないはずだが...なのに多くの人が、あたかもそのような振舞いと判断をしてしまう。潜在意識の Big Issue だから？ o 信用できないテストデータ も負債 o 現
エンジニアが作るネットサービスのアイデアがしょぼいワケ【えふしん】 - エンジニアtype | 転職type
Twitterクライアント『モバツイ』開発者であり、2012年11月に想創社（version2）を設立した有名エンジニア・えふしん氏が、変化の激しいネットベンチャーやWeb業界の中で生き残っていくエンジニアの特徴を独自の視点で分析 藤川真一（えふしん） FA装置メーカー、Web制作のベンチャーを経て、2006年にpaperboy&co.へ。ショッピングモールサービスにプロデューサーとして携わるかたわら、2007年からモバイル端末向けのTwitterウェブサービス型クライアント『モバツイ』の開発・運営を個人で開始。2010年、想創社（現・マインドスコープ）を設立し、2012年4月30日まで代表取締役社長を務める。その後しばらくフリーランスエンジニアとして活躍し、2012年11月6日に想創社（version2）設立 若干釣り気味のタイトルですいません。今通っている大学院の授業で、漫画家の浦沢直
株式会社時雨堂
おしらせ 2024.04.02 東日本電信電話株式会社様に「WebRTC SFU Sora」をご採用いただきました 2024.03.28 KDDI株式会社様に「WebRTC SFU Sora」をご採用いただきました 2023.12.20 「WebRTC SFU Sora」2023.2.0 をリリースしました 2023.12.04 年末年始休業について 当社では 2023年12月30日(土) 〜 2024年1月3日(水) を年末年始休業といたします 2023.11.22 当社は、Web プロジェクト用のリンターやフォーマッターなどを提供している Biome のゴールドスポンサーになりました 2023.10.26 当社は、C++日本語リファレンスを提供している cpprefjp のゴールドスポンサーになりました 2023.10.03 株式会社コナミアミューズメント様に「WebRTC SFU S
UI/UXデザイナー兼ソフトウェアエンジニアにジョブチェンジを果たした - id:anatooのブログ
もともと只のソフトウェアエンジニアだったのですが、最近になって肩書きが長くなりました。 何やってるのか やることが増えました。 UI設計 ワイヤフレーム作成 ビジュアルデザイン プロトタイプ開発 開発 エンジニアの頃は、一番下の普通の開発しかやってませんでしたが、ここ最近は上記のことをまんべんなくやっています。ワイヤフレーム作成では、アプリやウェブサイトの設計書となるワイヤフレームをOmniGraffleでガリゴリ書いています。その次のビジュアルデザインでは、PhotoshopやIllustratorなどを使ってアプリやウェブサイトの実際の見た目のデザイン作業をやっています。プロトタイプ開発では、実際に動作するプロトタイプ(ハイフィデリティプロトタイプって言うらしい)を作ってUI上の問題を解決していくということをやっています。UXに関してはこれらの作業全てを通じて改善に貢献するということを
職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;
Code Completeの上下巻を読んだ。 CODE COMPLETE 第2版 上 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazonCODE COMPLETE 第2版 下 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazon 読んだ感想としては、職業プログラマーなら必ず読むべき本だなと感じた。 この本ではソフトウェアコンストラクションに関する話題を扱っている。この本の中でソフトウェアコンストラクションとは、詳細設計、コーディングやデバッグ、単体テストなどなど、要求定義が終わった後、ソフトウェア製作に必要なプロセス全般のことを指している。 主なテーマとして、どうやってソフトウェアにおける複雑さを減らすことが出来るのか、について書かれている。そのテーマをいろいろな観点から説明されている。例えば以下の様な観点がある。 上流工程の欠陥による
権限委譲、リーダーシップ、チーム - naoyaのはてなダイアリー
いいか、覚えておけ。おれにしてもお前にしても、それなりに成功するってことは、なにかは得意なんだ。でも大体のことは不得意極まりない。全部自分でやろうとするな。自分よりも何かで優れている人たちが、その何かでお前のためにチカラを貸したいと思うような人間になれ。 それがリーダーってもんだよ。 この記事が話題になってた。リーダーシップというのは力を貸してやろうと相手に思われることだという、いい話。 この手の話は、誰もが否応なしに社会で経験することだから、みんなそれぞれ自分の考えを述べたくなる･･･という話題でもありますね。例に漏れず、自分も少し経験から感じることを書いてみよう。 「権限」を「委譲」する? 「上司が何かを部下に任せる」という文脈でいくと、このストーリーは「権限委譲」の話にもみえる。確かにテーマとしてはそうなのだが、自分は一般で言う「権限を委譲する」という考え方そのものにちょっとした落と
開発マネージャの役割
以前，開発マネージャの募集広告で，思わず首を傾げたくなるようなものを見たことがあります。そのひとつでは，たくさんのプログラム言語と開発環境について十分な知識を持っていることを条件にしていました。別の案件では，そのポジションの66%(なぜ2/3ではないのでしょう？)の作業はプログラミング，とありました。他にもPMO認定所有者を求めるものなど，そんな調子で延々と続いているのです。開発マネージャという役割が，ある意味で漠然としたものであることは事実でしょう。しかしこのような求人情報を見ると，募集を出している企業が開発マネージャの役割について本当に考えていないのではないか，という印象を受けてしまいます。雇用する企業にとっても，このような条件で雇用される側にとっても，これは不幸の元でしかありません。 開発マネージャであるあなたは，たくさんの責任を背負っていますが，もっとも重要なのは製品を出荷すること
5分で分かるデプロイ自動化への道
12月20日に第1回ワンクリックデプロイ勉強会で、デプロイの自動化について好き勝手に喋ったりデモしたりする予定なのですが、当日話す内容の概略について以下に載せておきます。 以下にあげることをやっておけばデプロイ自動化、ワンクリックデプロイはそんなに遠くないところにあると思います。 ソースコードのバージョン管理いわずもがな。全ての起点はここにあるコードの共同所有の原則への理解このソースコードは本番環境または開発環境などで同じように動作しなければならないテストを書く習慣、コミット前に他のテストも含めて通してからコミットする習慣設定ファイルのバージョン管理環境によって異なる設定値（接続先データベース情報など）が書かれた設定ファイルもバージョン管理する開発環境用、ステージング環境用、本番環境用などに分けて定義し、容易に切り替え可能にする本番環境に配置する際に、アプリケーションの各所を書き換えなけれ
方針設計 - Javaロギング
仕様で規定されているものは別として、プログラムの問題分析にはどのようなログが 理想的かは経験に基づく状況判断に依存するところが大きいところです。ここでは チーム開発におけるログ出力の方針などについて説明します。 一般的なシステム開発では統合テスト付近から後は開発物が開発者本人の手を離れて テストされることになります。同時に開発者は目の前で問題の発生を見られないまま 分析しなければならない状況が多くなってきます。 基本的にテスターなどからの状況説明、ログ、画面キャプチャなどから推測される プログラムの動きをソースコード上で追う事になるわけですが、問題の報告には 主観や個人の能力、勘違い、先入観などが入りやすいことも事実です。このような 中で客観性の高いログはとても重要です。 ソースデバッガやプロファイラは問題の詳細を調査するために大変有用なツール ですが、システム開発で使用するログとは目的が
うさぎとSEのブログ: ログに対する認識の甘さ
ソフトウェアを開発する方ならば、多くの方はログをプログラムから出力しているかと思います。 ログは例えばリリースした後に客先で動作しないなどの何らかの不具合が発生した際に、原因等を探るとても重要な情報源です。そのため、ログを適切に出力、保存されなければ、そのログはただ要領が大きいだけのゴミにしかなりません。 ただ、ログを出力するということは、 1. 何を出力するべきなのか？ 2. いつ、だれが、何に利用するのか？ 3. いつ出力するのか？ 4. 何を出力してはいけないのか？ 等を考えながら出力している方は少ないように思います。 ログを出力するときに、ログに対してもみなさんは設計書を作成していますか？ ばかばかしい、ログなんてメインの業務処理から考えればオプションのような位置づけだと思うかもしれません。 ですが、ログ出力を正しく行わないと、私の周りでは、今までこういった問題が発生してきました。
第1回 OAuthとは？―OAuthの概念とOAuthでできること | gihyo.jp
今回から始まった「ゼロから学ぶOAuth」。全4回の特集にて、これからのWebサービスを開発する上で不可欠な技術「OAuth」について取り上げます。初回は、OAuthの概念について取り上げます。 はじめに はじめまして、iKnow!改めsmart.fmの真武です。現在smart.fmでは、OAuthやOpenID、OpenSocial、Semantic WebやActivity Streamなどといった新しい技術の導入を積極的に行いサイトを活性化させるとともに、smart.fm APIを通じて我々の技術を外部のデベロッパの方々にも提供しています。 smart.fmは日本最大のOpenID Relying Partyであるだけでなく、国内では数少ないOAuth Consumer（後述）およびOAuth Service Provider（後述）を兼ねるサービスとなっています。こういった背景
継続開発のススメ - Twisted Mind
概要 開発をすればリリースがあり、リリースが終われば開発があります。継続開発をする以上はリリースと開発の繰り返しです。 開発手法やリリース手段は沢山あるのですが、あまりしっくりくるものが無かったので自分でまとめてみました。 これで完璧というものは残念ながらこの世にないと思うので、これからも臨機応変に良い流れを作って行ければと思います。 この文章は以下のような構成になってます。書き殴りですみません。 バージョンの付け方 ソースコード管理とリリース タスク駆動 環境方針 定義 いくつか事前に定義しておかないと話しが訳わからなくなりそうなので。 バージョン管理には git を採用しています。 開発というのはコードを書く事だけを指してはいません。 ここでいうフレームワークは「自身で開発している」として扱います。そうしないとちょっと難しいので。 ライブラリは自身の開発とそれ以外があると思いますので、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
APIオーケストレーション層
TechCrunch