残業も減らせる!? 上級エンジニアになるためのDesign Doc超入門：プロジェクト成功確率向上の近道とは？（3）（1/3 ページ） ITシステム開発の問題点の一つであるコミュニケーションの失敗。本連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は、「技術視点」のドキュメントとして、2000年代以降注目されている「Design Doc」について解説します。 IT技術がビジネスに貢献していくためには、まずはシステム開発を成功させることが重要です。本連載「プロジェクト成功確率向上の近道とは？」では、システム開発を成功させるために、コミュニケーションが果たす役割の重要性と、ドキュメントによるコミュニケーションの重要性について解説してきました。 連載1回の「ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門」、第2回の「サンプル例に見る
Equal OpportunityGoogle is proud to be an equal opportunity and affirmative action employer. We are committed to building a workforce that is representative of the users we serve, creating a culture of belonging, and providing an equal employment opportunity regardless of race, creed, color, religion, gender, sexual orientation, gender identity/expression, national origin, disability, age, genetic
プロジェクトメンバーが無駄に多いのが、日本型SIの特徴のひとつである。「工数を人数で割れば工期が出る」と考えることが間違いであることは、ブルックスの著書「人月の神話」によって今から40年前に指摘されている。それにもかかわらず、相変わらず多くのプロジェクトで必要以上の人数が投入されている。 私がとくに不思議に思うのが、基本設計を何人もの要員で分担するやり方だ。DB設計と機能設計と業務設計の担当を分けるとか、サブシステム毎に担当を分けるといった体制がしばしば敷かれる。詳細設計の段階でというのならまだわかるが、基本設計でそれをやってはいけない。 なぜか。業務システムにはアーキテクチャ（意図された構造）が求められる。そして、そこに含まれる膨大な定義要素は、統一感や一貫性を保ち、かつMECEな形で切り出されなければいけない。複数の要員で分担などすれば、それらの課題が一挙に難しくなる。また、DB構成と
受託開発やっている、いまの開発スタイルを書く。 この前のブログはわりとフォーカスをしぼったはなしだったので、今回は簡単に全体のはなし。（書く順番が逆っぽい） 今回のプロジェクトではアーキテクトとして、この↓開発スタイルの構築と運用をしていて学び多い。 バージョン管理はGit プロジェクト用サーバーにGitBucketをたててソースコードを管理している。 オフショアと仕事をするなど、開発拠点がわかれることが多い。 ソースコードに対してロックをとったりしちゃうと、他の人が開発すすめられなくなるし、拠点別れて並行開発する大規模案件だからこそ、Gitを使う必要がある。 各開発者がブランチをきって開発をして、プルリクでレビュー依頼、からのマージをすることで、レビューが済んでいるソースしかmasterブランチに取り込まれない、というのもイイ。 弊社の”エンジニア”はみんな当たり前のようにGitを使って
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
2024-08-07 研修終了後ブログ BN研修の締めとして振り返り #エンジニア #新卒 #研修 2024-07-31 【24卒】FLINTERSエンジニア研修を終えて 研修 株式会社FLINTERSに新卒でエンジニアとして入社し、3ヶ月間の研修を終えたのでその概要をお伝えしようと思います。 #24卒 #25卒 #研修 #新卒 #新卒エンジニア 2024-07-24 雰囲気と研修内容：FLINTERSの新入社員の3ヶ月振り返り 2024年度BN研修まとめ 2024-06-21 Webフロントエンドプロダクト用にテスト戦略を考えた話 ブログ祭り梅雨 Webフロントエンドプロダクト用にテスト戦略を考えた話 2024-06-21 今期振り返り ブログ祭り梅雨 今期振り返り #今期の振り返り 2024-06-21 今期の振り返り AWS ブログ祭り梅雨 今期の振り返り #AWS 2024-06-
今日は、開発者が見積もりを作成している時に脳内でどんなことが起きているのか話してみたいと思います。なぜこんなにも見積もり作業が難しいのか、そして、私の見積もり精度は相変わらずひどいものですが、私がどうやって（非常に幸せな事業主の方々に向けて）ソフトウェアを書いて生計を立てる術を編み出してきたのかについてお話ししたいと思います。 まずは昔話をひとつ。 あれは\<私がものすごく年寄りには見えない程度の年代をここに挿入>頃でした、私は年若き開発者でした ^(1) 。大学のコーディング演習では優秀な成績を修め、若手開発者として誰がどんな問題を提示してきても解決し、想像を絶する速さでどしどしコードを量産していました。新しい言語は週末の間に習得し、書けるようになっていました（少なくともそう信じていました）。 それで自然な流れとして自分でプロジェクトを取り仕切ることになりました。アカウント・マネージャが
メソッド名などをネーミングする際に、知っておくと便利な、接頭辞と接尾辞をリストアップしてみました。どのように元の単語の意味が変わるかのルールを知っておくと、よく使う単語をベースにボキャブラリーを増やすことができるので、覚えておいて損はないと思います。 使う場合は、当たりを付けて実際の使用がないか、Googleなどで調べてみてください。 1. pre-, post- / 事前〜、事後〜 per-は、元の意味に “事前に、前に”、post-は “事後に”という意味が付け加わえます。汎用性が高いのでとても便利です。afterやbeforeの代替になるかもしれません。 // 事前テストする function testBefore(); ↓ function pretest(); // 事後処理する function executeAfter(); ↓ function postexecute();
モバイルファースト室の山下( @tomorrowkey )です。 みなさんはAndroidアプリをビルドするときに AndroidStudioの実行ボタンを押すのと、ターミナルでgradleコマンドを実行するのと、どちらを使っていますか。 クックパッド社内のAndroidエンジニアでもどちらを使うか好みが分かれるのですが、私はたいていターミナルでgradleコマンドを使っています。 AndroidStudioの実行ボタンだとビルドを途中で中止できないことがあるからです。コマンドであればcontrol+cでいつでも中止できるという気軽さからコマンドを好んで使用しています。 開発するうえでIDEなどのGUIツールはとても便利なのですが、実はコマンドを実行する方がはるかに早くストレスなく開発を進めることができることがあります。 今回は私が実際に使っている便利なコマンドラインスクリプトを10個紹介
はじめまして、11月頭にクックパッドに入社したモバイルファースト室のヴァンサン(@vincentisambart)です。 既存のiOSアプリのiPhone 6と6 Plus対応について書きたいと思います。 既存のiOSアプリはiPhone 6対応済みだと明確にOSに示さないと、iPhone 6でも6 PlusでもiPhone 5の画面を拡大したものが表示されます。アプリから見える画面のサイズはiPhone 5と同じ320x568です。 iPhone 6対応がされていると示すには、方法が2つあります： 静的起動画面：iPhone 6とiPhone 6 Plusの画面サイズに合わせた静的な起動画面用の画像をアプリに入れます。 動的起動画面：起動画面をXIBファイルという形でアプリに入れます。 iOS 7以下は動的起動画面を対応していません。iOS 7以下対応のアプリが動的起動画面を使っても問題
Yosemiteでアプリの画面を動画キャプチャー出来たのは、良いが、iPhone6(1334×750), iPhone6 Plus(1920×1080)のどちらかしか端末を持っていない場合、もう片方のサイズの動画の作成と、フレームレートのエラーが頻発し、戸惑ったので、メモ。 動画のサイズ変換には、なんとQuickTime 7 Proを3,000円で購入！ 任意の動画サイズで、書き出しが可能！1920×1080の動画をキャプチャー出来ていたので、QuickTime 7 ProでiPhone6の1334×750の動画を作成しました。 QuickTime 7 Pro 登録キーの登録方法 http://support.apple.com/kb/HT2240?viewlocale=ja_JP&locale=en_US 1. もとにする動画ファイル(mov )を読み込む 2. ファイルから書き出し
https://gdstechnology.blog.gov.uk/2014/10/01/cdn-acceptance-testing/ 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約2時間前 Code for Americaなど、ネットの力で政府機関を改善していく取組みがここ数年増えていますが、中でもGOV.UKは、英国政府のwebサービスのあるべき仕様をサービスデザインマニュアルに詳細にまとめ、政府関連のウェブサイトを取りまとめています。その活動は、3分ほどのビデオにまとめらてますが、技術関連の情報発信にも力を入れてきています。 さて今回のGOV.UKのエンジニアブログは、受け入れテストを充実させてCDNの挙動を検証した取組み。実装の詳細から、バグのケースまで網羅されていて、かなり詳しく紹介されています。合
業務でソースコードレビューを行う機会が増えたので、複数回指摘した項目や気になった実装などをまとめてみました。 こういう観点をできる人と共有できるといいなあ…。 2014/09/29 23:00 一部修正しました。 業務上ソースコードレビューの名目で仕様・デザインまで見ることになっていたためこれらを先頭に書いていましたが、わかりづらかったため最後にまとめました。 Fragment関連 FragmentとActivityの密結合 Fragmentが特定のActivityから呼ばれることを想定して書かれている場合、そのFragmentとActivityは密結合である場合が多いです。 具体的には、以下の様な実装です。 ActivityのViewを参照する Activityのメソッドを直接呼び出す なぜダメか Fragmentの利点のひとつは優れた再利用性にあります。 Fragmentが特定のAct
UXチームの責務は、ユーザーにとって望ましいエクスペリエンスを作り出すことである。にもかかわらず、ユーザーを開発プロセスに巻き込んでいない組織は多い。顧客からのインプットがない組織は役に立たないインタフェースを作り出してしまう危険がある。 UX Without User Research Is Not UX by Hoa Loranger on August 10, 2014 日本語版2014年9月18日公開 Webサイト（あるいは製品）の成功はユーザーからどう思われるかにかかっている。ユーザーはWebサイトの有用性と使いやすさを、そのサイトとインタラクションしながら評価し、数秒、ときには数ミリ秒で結論を出す。 あるサイトに関与するかどうかのユーザーの判断の基準になるのは、「そのサイトは自分にとって価値があるか。使いやすいか。そこでのエクスペリエンスを楽しめるか」といった問いである。ユーザ
CloudFront のアクセスログを S3 に出力するように設定していると、日に日に大量のログファイルが溜まっていきます。 中には 1 MB 程度のファイルもあれば、数百 bytes 程度の小さなものもあります。 何にせよ、とにかく大量にあります。 小さいファイルはまとめるCloudFront のログのように小さいファイルが大量にあるようなケースは Hadoop が苦手とするパターンで、そのまま扱うと大抵めちゃんこ時間がかかります。 そういう場合は、S3DistCp という便利ツールを使って S3 上のログファイルをもうすこし大きいサイズに連結して、HDFS にコピーするとパフォーマンスがあがることがあります。 ちなみに、EMR のベストプラクティスによると、Gzip で圧縮されている場合は 1 ~ 2GB、LZO で圧縮されている場合は 2 ~ 4GB が最適なファイルサイズらしいです
CEDEC2014にて発表させていただいた内容です。 発表日時 : 2014年9月4日(木) 13:30～14:30 公式URL : http://cedec.cesa.or.jp/2014/session/BP/16553.html 中継URL : http://www.ustream.tv/channel/cedec-ust-c Mobage Developers blogでの予告 : http://developers.mobage.jp/blog/notice-of-cedec2014 反応 : togetter等でとりまとめ予定 セッションの内容 ■ビッグデータという言葉が一般化しつつある昨今、より重要なのは、データを適切に解釈し、価値を生み出す「アナリティクス（分析）」であると言われています。ゲームアプリやソーシャルゲームの世界においても、データからどのようにゲームを面白くする
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム＆リーンスタートアップ導入)について #devlove #devlove創 ★最新版の45分拡大版はこちら http://www.slideshare.net/i2key/45-developers-summit-2015-devsumi-devsumib 社内スタートアップが成長していく過程で直面した様々な問題についてcameranの事例を元にお話します。また、その問題に対して、スクラムやリーンスタートアップを用いてどのように解決していったのかについて説明します。 ※スクラムやリーンスタートアップについての基本的な説明は省略
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
