海外のプログラマーにバグを指摘し、修正を依頼するには【連載:コピペで使えるIT英語tips】 - エンジニアtype
トップページ > ノウハウ > コピペで使えるIT英語tips > 海外のプログラマーにバグを指摘し、修正を依頼するには【連載:コピペで使えるIT英語tips】 グローバル化が進む中、海外企業とのやり取りが増え「英語でのコミュニケーションが求められる」というエンジニアも多いはず。 しかし、「英語でどう伝えればいい？」、「場面に応じた表現が分からない」など、英語でのやり取りに実務以上の時間を取られてしまっているという悩みを抱えているのが現状ではないだろうか。 そんな皆さんの悩みを解決するべく、通常の業務の中で必要となる「今すぐ使える英語の例文や用法」などの英語tipsを連載で紹介。 初回となる今回は、エンジニアであれば誰もが必ず直面する「bug（バグ）の指摘の仕方」について紹介する。 バグを指摘する際には、「bugがあるから直してくれ」と伝えるだけでは適切ではないというのは当然のこと。日本語
ソフトウェア開発にとって最大の阻害要因は納期 - 狐の王国
えっらそうに大規模開発を語るような立場じゃないんだけど、何かと話題のこのへんの記事を読んでいろいろと日ごろ思うところがふつふつとわいてきたので……。 Life is beautiful: 特許庁のシステム開発が破綻した本当の理由 Fumi's Travelblog: "費やした55億円、水の泡に 特許庁がシステム開発中断"って一体何だったのか、報告書を読んでみた 特許庁システムのことはそれなりに話題で、日本についてから何度も話にあがってきている。まあ不祥事だのなんだのって話もあるがそれはおいとくとしても、設計段階で60人体制ってだけでも多すぎるのに、増員で1300人体制とか……。設計を穴掘りかなにかと勘違いしてるとしか思えない対策でそりゃまあ破綻するよなあと。 それからね、中嶋さんの記事のコメント欄に書き込まれてた、よく言われる大規模開発でのこのへんの話。 SIerが開発を行う場合、この1
html5j.org
html5jについて html5jは、HTML5などのWebプラットフォーム技術を使った「ものづくり」に関わるすべての人々を応援する、非営利・中立のコミュニティです。私たちは、日本のWebクリエイター・エンジニアのスキル向上をお手伝いして、日本が世界のWebシーンをリードするような存在になることを心より願っています。 html5jの活動 html5jはWebクリエイター・エンジニアの皆さんに対し、「つながる」「学べる」「盛り上がる」を合言葉とし、以下の活動を行なっています。 html5jメーリングリスト Web開発に関する話題について質問したり、共有したりするためのメーリングリストです。また、勉強会の告知なども行なっています。 html5jメーリングリストに参加する （Googleグループに移動） 投稿ルール HTML5などの技術やWeb開発に関する話題であれば、どんな内容でも構いません。
ぼくが実際に運用していたGitブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
1日に175回もGitHubはデプロイしているだとぉ…！？ | Act as Professional
GitHubは普通の会社とどう違うのか？ リリースマネージャーがいない（いる必要がない） 週次のデプロイセットもありません（この週にこれだけの機能をまとめてリリースとかがない） 開発者とデザイナーは、早く提供できるように自分たちでデプロイする（できる）作った人達が自ら確認できて、サクッとデプロイできるのであれば、さっさと作って、ささと出してしまった方が良いに決まっています。これを実現させるために様々な工夫がされているようです。 GitHubの基本的なワークフロー The basic workflow goes like this: Push changes to a branch Wait for the build to pass on our CI server Tell Hubot to deploy it Verify that the changes work and fix a
チケット駆動開発 no ticket, no commitは誤解 | Act as Professional
チケット駆動開発を誤解していた@HIROCASTERでございませう。 チケット駆動開発（TiDD）の提唱者である方の書籍が8/24(金)に発売されます。 なんと、これまでチケット駆動開発は no ticket, no commit（チケットがなければコミットできない）というルールが絶対だと理解していたですが、著者みずからが、これはテーラリング（プロジェクトの特性に合わせて手直しする）の対象であると述べています。 基本的なルールですが必須ではありません。12章のテーラリングガイドの対象の一つになっています。 RT @ryuzee: チケット駆動開発本を買うかどうか悩んでいるのだが、No Ticket No Commitは僕は守るつもりのない行動なので、それが前提だとつらい。どうなんだろ — さかば (@sakaba37) August 16, 2012 チケット駆動開発に対する考えno ti
チーム開発を円滑にするための必須ツール
はじめに 先日Googleが「世界のスマートフォン利用に関する大規模調査」にて2012年度版の調査結果を公開したところによると、日本のスマートフォン普及率は20%だそうです。昨年2011年は6%だったので、約3倍普及していることになります。 このようにますますスマートフォンのアプリ需要は増大しており、その開発も、より効率的に行っていく必要があります。 本連載では、DaVinciWare様と株式会社ソニックガーデンで共同開発したiPhoneアプリ「AnkiBlank」を題材に、サーバサイド連携を必要とするスマートフォンの開発について、事例を交えて説明をしていきたいと思います。 iPhoneアプリ「AnkiBlank」のご紹介 突然ですが、中学生や高校生の時に暗記シートを使って単語を覚えていた経験はありますか？ 個人的には歴史の年号や出来事を、文脈と一緒に覚えるのに使っていた記憶があります。「
2012年に開発者が学ぶべき10のスキル
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます ここ数年、ソフトウェア開発の世界は比較的穏やかだった。しかし、HTML5が地歩を固め、Windows 8がWindowsの開発シーンに大きな変化を迫っている今では、ジェットコースターの日々が戻り、スピードはますます上がってきている。もし最先端に居続けたいのなら、少なくともこの記事で挙げる10のソフトウェア開発スキルを身につけることを検討すべきだ。 1．モバイル開発 モバイル開発を学ぶのに時間を割く価値などないと考えているのなら、考え直した方がいい。2011年のAndroid携帯の世界出荷台数は、ほとんどPCの販売台数と同じだ。他の有名なモバイルデバイス（iPhone、iPad、そして「瀕死状態」のRIMデバイス）を加えれば、販売台数で見
マイクロソフトの責任者が語る「われわれはどのようにソフトウェアをテストしているか？」 JaSST'12 Tokyo
マイクロソフトの責任者が語る「われわれはどのようにソフトウェアをテストしているか？」 JaSST'12 Tokyo ソフトウェアのテストに関わるエンジニアが集まる国内最大のイベント「ソフトウェアテストシンポジウム JaSST'12 Tokyo」が1月25日、26日の2日間、都内で開催されました。 10周年を迎えた今回のイベントの基調講演を行ったのが、開発しているソフトウェアの規模、分野、種類において世界最大の企業、マイクロソフトのプリンシパル テストリードのBj Rollison氏。 「How We Test At Microsoft（マイクロソフトでどのようにテストをしているのか？）」という題で、同社がどのようなソフトウェアテストを行っているのかを中心に講演を行いました。講演の内容をダイジェストで紹介しましょう。 開発者とテスターはほぼ同数 マイクロソフト プリンシパル テストリードのB
ソフトウェア技術者軽視のシステム開発を続けるのはもう限界かもしれない - 達人プログラマーを目指して
つい先日、富士通がグループで抱える3万人ものSEを再教育して、職務転換を行う計画であるというニュースを知りました。 富士通の3万人SE職務転換大作戦は成功するのか？ - GoTheDistance 一つのシステムを複数の企業などが利用するクラウドサービスがこのまま普及すれば、顧客の要望を聞いて個別システムを作り込むＳＥは仕事がなくなり、余剰人員問題が顕在化するからだ。 クラウドの普及により、オーダーメイドでシステムをゼロから構築する必要がなくなり、そもそも顧客からの要件をまとめてシステムを設計するSEの仕事が不要になったり、基盤を構築、運用するエンジニアが不要になるということは、最近になってよく言われることであり、特に新しいことではありません。もちろん、クラウドの普及によって、これらの伝統的なSEの仕事が少なくなり、人員が余るという議論は間違いではないと思います。 ただし、一方でより本質的
品質に厳しい組織で、なぜ品質が劣化するのか？ - 現場のためのソフトウェア開発プロセス - たかのり日記
このエントリーは「Software Test ＆ Quality Advent Calendar 2011」における12/18分として書いています。 12/17は @NoriyukiMizuno さんによる 「ソフトウェアテストの勉強会。1年目。」 というエントリでした。 今回は、以前から感じている矛盾について、私なりの考えをまとめたものです。 特に、マネージャーや経営層と呼ばれる人に読んでもらいたいと思っているのですが、このブログの読者層を、考えると、あまり多くはなさそうなので、以下に示す問題について、悩んでいる／苦しんでいるような人から、うまく伝われば良いと思っています。 矛盾する問題 私は、SEPG（Software Engineering Process Group）という役割上、いろいろなソフトウェア開発のプロジェクトや組織に関わってきました。 絶対数で言えば、そんなに多くはない
SIerにはコード記述の自動化からビルド・デリバリの自動化へのトレンドの変化を理解してほしい - 達人プログラマーを目指して
ちょっと前にTogetterで作成したまとめに対して大きな反響をいただきました。 SIerは自動化する対象が違っているのでは？ - Togetter これは、私が Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler)) 作者: Jez Humble,David Farley出版社/メーカー: Addison-Wesley Professional発売日: 2010/07/27メディア: ハードカバー購入: 3人 クリック: 141回この商品を含むブログ (23件) を見るを読み始めて、ふとつぶやいた をきっかけに始まったTL上での議論をまとめたものです。この本は、7月に行わ
App Store登録もOK！JavaScriptで作るiPhoneアプリ
Webアプリケーションは、傾きセンサやGPSからの情報取得やバイブレータ動作などのOSの機能の利用に制限があります。また、オフラインでの動作ができません。 開発の容易さは、若干主観めいてしまいますが、コンパイルが必要でメモリ管理も必要なネイティブアプリに比べて、Webブラウザでリロードするだけで最新のコードをテストできて、基本的にメモリ管理も不要なWebアプリケーションに軍配が上がります。 ネイティブアプリケーションの最大のメリットは、「App Storeでの配布ができる」ことで、多くのユーザーが集まるApp Storeでアプリケーションを配布でき、さらには課金もできてしまう点です。 ローカルWebアプリという第3の選択肢 前段の機能比較表に「ローカルWebアプリケーション」という項目があります。これは、Safariでオンライン中に所得したHTML、CSS、画像データなどを保存して、オフラ
社内で立てたいWebベースのSubversionリポジトリブラウザ·sventon MOONGIFT
sventonはJava製WebベースのSubversionリポジトリブラウザ。 sventonはJava製のオープンソース・ソフトウェア。個人の間ではGitやMercurialといったバージョン管理システムがもてはやされているが、企業においてはまだまだSubversionが強い。機能的にも十分であり、社内開発であればあえて乗り換える理由がない場合も多いだろう。 そんなSubversionの管理ではTortoiseSVNが使われているだろうが、非開発者が使うならばWebベースのが良いと思うはずだ。そこで使ってみたいのがsventonになる。 sventonはWebベースのSubversionリポジトリブラウザだ。階層をそのまま表示してフォルダを辿りながらファイルを閲覧していくことができる。またコミットログを閲覧してファイルの差分を確認することも可能だ。差分はDiffとして表示することもサイ
プログラマーの情熱を奪わない開発プロセスとは？ | スラド デベロッパー
テスト駆動開発はベストプラクティスであるということは皆の知るところだろう。コードを100%レビューする。単体テストでのコードカバー率を70%にする。循環的複雑度を20以下に抑える。開発を始める前に顧客の要望を調整しておくなど。大量の「ベストプラクティス」は、それぞれ素晴らしいアイディアのように見える。しかし、ベストプラクティスをこなすことに追われる開発者には、革新的・創造的な作業をするための時間がどれぐらい残されるだろうか。 O'Reilly Radarの記事では、良いコードを確保するために取り入れるプロセスが多すぎると、開発者の情熱を奪ってしまうと主張している。 「素晴らしいコードを書くことのできるプログラマーから、プロセスが情熱を奪う。不満を抱くプログラマーが質の悪いコードを書き、良いコードを確保するために管理部門がプロセスを追加する、という悪循環に陥り、さらに士気が低下する」というこ
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ボクの開発スタイル
http://homepage2.nifty.com/yoks/TechNote/H2/H2_MnFrm.htm
国内の開発者が使っている言語、1位C、2位VB、3位Java。アジャイル開発は2割が採用、半数以上がウォーターフォール。IDC調べ
その一方で、ウォーターフォールの現場にて開発者が出来ること
