![10GB以上のファイルも登録不要で送受信できる「Send Anywhere」【仕事お役立ちアプリ】](https://cdn-ak-scissors.b.st-hatena.com/image/square/32cb94024e3afa958c39d3ff4f9b0d80e6d51a15/height=288;version=1;width=512/https%3A%2F%2Finternet.watch.impress.co.jp%2Fimg%2Fiw%2Flist%2F1087%2F537%2Fimg_00_o.png)
自動化することによりあなたはレビュアーとしてより価値のある貢献ができるようになります。importsの順序やソースコードのファイル名の命名規約などの問題を無視できるならば、機能上の誤りや可読性の問題といった、より関心のある問題にフォーカスすることができます。 オーサーもまた自動化の恩恵を受けます。ケアレスミスを見つけるのに1時間浪費することなく、即座に見つけられます。即座にフィードバックを受けられることで、関係のあることがオーサーの頭に残り、これにより学習が容易となり、修正コストが低くなります。それに加え、彼らが初歩的な誤りについて指摘を受ける必要がある場合、あなたから指摘を受けるよりコンピューターから指摘を受けたほうが彼らの自尊心の観点からはるかに気分がよいわけです。 これらの自動チェックはコードレビューのワークフローの中に入れましょう(例えば、Gitのコミット前のフックやGithubの
SPI Japan 2017というカンファレンスで発表をしました。 グロースフェーズの痛みの中で、いかに開発・運用チームを立て直したかという内容になります。 発表スライド 「Rebuild Team - 急成長プロダクトのDev&Opsで生じる悪循環とその解決策」 ここ最近の発表の集大成です。 急成長フェーズを体験した人は多くないはずなので、有用な知見ではないかと自負しています。 参加した感想 運営が非常に丁寧でした。選考通過時にはレビュアーから「こういう点が素晴らしい」とコメントいただき、また当日には司会者からフォローをいただき、非常に話しやすい場作りがなされていました。 一方で内容面については全体的に違和感を覚えました。もやもやです。 内容 思ったこと 補足事項 「改善施策が現場に受け入れられない」という意見が多かった 改善施策は現場の人が現場のために生み出すものではないか。 現場にメ
弊社では、案件とは関係のないプロジェクトでも業務時間中にみんなにコードレビューを依頼できる時間が確保されています(参加は任意)。案件のコードレビューを依頼したり、ちょっとした個人の制作物を見てらったりと使い方は色々です。 先日、TypeScriptの練習にQiitaのAPIを叩いていて記事を表示するブログウィジェットを作成しました。このウィジェットのレビューを依頼したところ、クラスの設計について具体的な指摘と、それに対する改善を経験できたのでこの記事に記載します。 今回作ったQiitaWidgetの要件 Qiitaの公式APIV2から記事とユーザー情報を取得し、HTMLテンプレートに表示する 投稿の合計いいね数を算出するために、あるユーザーの投稿を全件取得する (このために複数回リクエストの送信とレスポンスデータの結合を行う) パラメータによってユーザー、いいね数によるソート、表示件数、ラ
All slide content and descriptions are owned by their creators.
誰かと開発することを忘れかけていて、 もぅマヂ無理。。。とりあえずLGTMしょ。。。 となりかけてしまったので、尊敬できるエンジニアである夫に相談してみました。 世の中の正解かは分からないですが、私は参考にしたいと思ったのでまとめます。 レビューの仕方がわからないです!!どこから見たらいいかわからないです!! プルリクでは「意図」がわかるようにしたほうがいい。 夫が所属しているチームでは下記の内容をプルリクの説明(description)に書いているそうです。 なぜこの変更を入れるのか バグだったらどういう問題があったか、機能だったらこれを入れたら何が改善されるのか(なにが嬉しいの?) 変更概要 変更概要を読むとdiffを見たときに意味がわかるように こういう理由でこういう実装になっている、こういう理由でここは直さなくてもいい、などを書く 関連Issue チケット(issue)へのリンク
ソフトウェアを作っていて,一人でずっとやってると不安になったり,他人がずっと一人でやってると心配になったりする. ふつうのチーム開発では,仕様や方針は皆で合意が取れていて,実装したところは「きのう話していたこの部分を作ってきました,レビューしてください」みたいな話をする 一方で,チームでやっていても,一人で仕事していたら,「実は私はこういうことをやっていて,その上で,この部分を作りました,仕様を理解した上でレビューしてください」みたいな話になる このとき,「実はこういうことをやっていて」という部分を一人でやっていると,見逃していたり,誤解していて,前提から間違っていて,まったくもってだめ,という可能性が上がっていく 一人で作り続けると,一人につき1回10%間違えるとしたら,2回一人で作ると,0.9*0.9=0.81くらいの精度に下がっている 設計段階で二人で見ていれば,間違う可能性は1-0
メモというのは大事なもので、蓄積されたメモは後々大きな意味をもってきます。そのためにも手軽に、かつ一カ所にまとめて書けるようになっていなければなりません。散在したメモは探すコストが大きく、役に立ちません。 会社であればメモはみんな一カ所に書きためるべきです。それによって知らなかった新しい知識に辿り着けます。それを可能にするのがCrowiです。 Crowiの使い方 まずログインします。 こちらがメモの画面で、ビューワーにあたります。 こちらはプロフィール画面。この画面も編集できます。 右上のアイコンをクリックすると新しいメモが作成できます。 編集画面です。Markdownを使います。画像のアップロードはドラッグ&ドロップでできます。 自動的にURLが変わって、プレビューも更新されます。 更新履歴も表示できます。 Crowiはグループで利用できるWikiエンジンで、ブラケット名も利用できます。
アトラシアンが「Stride」発表。グループチャットを中心にビデオ/音声会議、タスクアサイン機能など。無料利用も提供でSlackを追撃 アトラシアンは新しいコミュニケーションツール「Stride」を発表しました。同社からクラウドサービスとして提供されます。 Strideはグループチャットやチャットやビデオ会議、チャットの内容をタスクとしてメンバーにアサインする機能など、統合コミュニケーションツールにタスク管理機能を加えたものです。 Slackのようなグループチャットにビデオ会議付き Strideの基本機能はSlackのようなグループチャット機能です。各種クラウドサービスとの連携、ファイル添付、ダイレクトメッセージ、検索、部屋ごとの通知などを備えています。 そのうえでStrideは音声や動画を用いたビデオ会議機能を搭載。画面共有も可能で、デスクトップやモバイルなどのクロスプラットフォームでリ
みなさんこんにちは。@ryuzeeです。 スプリントをずっと回していると、「いつもスプリントに追われている気がする」「一回立ち止まってゆっくり考えたい」「情報共有ができていない気がするので整理したい」「技術検証をもっとやりたい」「勉強時間をとりたい」といった話を聞くことがあります。 それに対して、どのように対処していくべきか考えてみましょう。 考えられる対応策はいくつもあるので、まずはそれを列挙します(ダメなものも混ざっています) 複数回スプリントを実施したら、1回分のスプリントでは開発チームは好きに活動する(✕)スプリントとスプリントの間に休憩を入れる(✕)フィーチャー開発以外の取り組みを行うスプリントを必要に応じて用意する(△)スプリントのキャパシティを見直して、開発チームが持続可能なペースで働けるようにする(◎)それぞれを順番に見ていきましょう。 複数回スプリントを実施したら、1回分
本連載「こっそり始めるGit/GitHub超入門」では、バージョン管理システム「Git」とGitのホスティングサービスの1つ「GitHub」を使うために必要な知識を基礎から解説していきます。具体的な操作を交えながら解説していきますので、本連載を最後まで読み終える頃には、GitやGitHubの基本的な操作が身に付いた状態になっていると思います。 前回記事「たった3つで共存できる、Git/GitHubとSubversion(SVN)の連携、移行に関する基本操作」では、Subversionとの連携や移行について解説しました。 本連載の最終回となる今回のテーマは「Git/GitHubのワークフロー」です。幾つか存在するバージョン管理のワークフローのうち「git-flow」「GitHub Flow」の概要を解説します。 git-flow 「git-flow」はVincent Driessen氏の「A
こんにちは、エンジニアの@sota1235です。 タイトルの通り、今回は愚直に改善をした話をします。 メルカリのJavaScript メルカリにおけるJavaScriptの活用場面は以下のようなものがあります。 メルカリWeb アプリ内Webview 社内ツール React Native Node.js製のbotやGoogle App Scripts etc… いずれもサービスにとって重要なものであり、サーバサイドエンジニアであってもJavaScriptに触る機会は少なくありません。 かくいう私も普段はサーバサイドエンジニアですが、JavaScriptコードを書いたりレビューする場面が多くあります。 そんな中でWebチームにおいて、JavaScript開発でいくつか問題がありました。 課題その1: JavaScriptのレビューコスト問題 1つ目の課題としてJavaScriptのコードをレ
Mercari Android チームの @tsuyogoro です。US 版 Mercari Android アプリの開発を担当しています。 この度、より一層 US マーケットにフィットしたアプリをユーザへ提供し US での成長を更に加速すべく、US 版 Mercari を刷新しました (https://play.google.com/store/apps/details?id=com.mercariapp.mercari&hl=en) 。 クライアントアプリだけでなく API サーバのアーキテクチャも変わり、文字通り大変更が施された訳ですが、本記事ではスクラッチから書き直した Android アプリにフォーカスを当て、何が変わったのか / これによってチームはどう変わったのか、という事を紹介します。 UI が大きく変わりました Before Mercari が US でリリースされたの
一日だいたい8時間、今日まであわせて60営業日くらい、固定ペアのペアプログラミングで新規アプリのクライアントからサーバまで開発してみました。チームにエンジニアがちょうど二人だったので。 もはや日常がペアプロです。ペアプロ以外でやってるのは簡単なバグ修正やちょっとした環境整備で、あとはすべて二人で開発しています。ちなみにまだまだ続いています。狂気です。 いい大人が二人集まって狂気を選ぶことになったわけは、成果も出てないしまだ書けません。でも今って、ペアプロやモブプロがブームだって聞きました。それじゃあアホみたいにやってる人間としては黙ってられないです。基本的なことはおいといて、とりあえずこれだけはってつくづく思ったのとか、ペアプロを有意義に長く続けるコツをまとめてみました。 (ちゃんとした話は ペアプログラミングの5W1HとFAQ / 5W1H and FAQ of Pair Program
こんにちは。 @at_grandpa です。普段はバッチを書いたりメンテナンスをしています。 今回は、先日起きた障害対応の時、チームの状態をスムーズに変えることで対応コストと精神的負荷を抑えられた、ということを書きます。 目次 目次 障害発生 普段の対応 今回の対応 原因究明と現状把握 関係者が会議室に集まる 対応用Slackチャンネルを開設 ペアワークで実対応 落ち着いたら自席&Slackコミュニケーションへ移る 対応完了の確認と報告・チケットまとめ まとめ 障害発生 先日の朝に「レポートの数値がおかしい」という連絡がきて確認したところ、とあることが原因で、バッチの自動実行が約半日行われていないことがわかりました。 普段の対応 普段の対応は以下のような形です。 エラー発生をSlackの全体チャンネルで報告 バッチ系チャンネルにて、考えや現状を垂れ流す わからないことがあれば有識者にメンシ
755でAndroidアプリ開発を担当している前川(@kaelaela31)です。 本日Androidアプリをリリースし、今回紹介する動画編集機能のアップデートを行いました。今回のアップデートでは、いつもと少し違う開発の進め方をして、結果として機能改善と良い開発体験ができたので、みなさんの現場でも参考になればと思い記事にまとめました。 機能改善の進め方について みなさんのアプリ開発では、デザイナーやディレクターとどのようにして進めているでしょうか。以前にFRESH! AndroidアプリのUI/UXという記事で荒谷が紹介していたFRESH!の開発手順は以下でした。 基本的なデザインに関してはデザイナーがSketchでモックを作成した後にエンジニアとディレクターで仕様を踏まえつつ議論を重ねてブラッシュアップをしていきます。その後、各クライアント(Android, iOS, Web)に沿ったデ
AbemaTVアプリ開発の裏側──若手エンジニアを磨き上げる「改善志向型エンジニア文化」とは? 「若手エンジニア、どんな活躍してますか?」の第8回目は、話題のインターネットテレビ局、「AbemaTV」のアプリを手がけるエンジニアの登場です。精鋭揃いのAbemaTVチームでは、どのような研鑽があるのでしょうか。 サービスの会社──。 サイバーエージェントという企業に、こんな印象を持つ人は多いでしょう。アメーバブログやAWA、そしてAbemaTVといった、センセーショナルでポップなサービスを次々と展開しているから、こう感じるのかもしれません。 言うまでもなく、こうしたサービスの裏側には、エンジニアたちの奮闘があります。つまり、「サービスの会社」とは、「エンジニアリングの会社」と言い換えることもできるのです。事実、現在サイバーエージェント社の全社員の3割強がエンジニア職にあるといいます。そして、
こんにちは、サーバエンジニアのひっしーです。 この7月でTimersに入社して1年の自分が、この度プロジェクトマネージャ(PM)にチャレンジします。当然、強制ではなく自身の希望で、プロダクト開発に関わる様々な経験を積んでみたいという気持ちからです。そしてそれをGoしてくれる会社、なんて柔軟なんだ…ありがとうございます。 というわけで今回、エンジニアからPMまで経験する私がチーム開発について書いてみます。 Timersのプロジェクトチーム体制 1年かけて学んだ、成功のために大切なこと ポジティブ 日々の会話 自責 Timersのプロジェクトチーム体制 Timersでは、プロジェクトを推進するにあたり各プラットフォームからメンバーが集まりチームを組織します。 プロジェクトマネージャ(PM) デザイナー Androidエンジニア iOSエンジニア サーバエンジニア 基本的に各プラットフォームから
最近、ソフトウエア開発にて、テスト技術者が要件定義からレビューに入る件について、いろいろ話を聞いたので、まとめておきます。 これは、ちょっとかっこよく言うと「Wモデル」という、テスト担当者の作業と開発の作業を同時並行で行っていくVモデルの進化した開発モデルが目指すゴールの一つです。ただ、話をしてくれた人は、Wモデルという言葉を知っているわけではありません。 その人の組織では、1980年代後半から、独立したテストを行っているとのことです。開発したものの統合テスト以後のテストだけを請け負うテスト専門部隊です。 Windowsが出る前はCOBOLで作った会計プログラムを対象にしていて、それがWindowsが出たころに全てWindowsアプリになり、それが今では全てWebアプリになり、クラウド上で動くようになっているという感じです。今では、そこの組織では、要件定義の段階からドキュメントをテストチー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く