質とスピード(2022春版、質疑応答用資料付き)
![質とスピード(2022春版、質疑応答用資料付き) / Quality and Speed 2022 Spring Edition](https://cdn-ak-scissors.b.st-hatena.com/image/square/6a842e0cdaca4b59b4a7526df7802187f71c023a/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F0d45756f147d45229020083eb2dd139c%2Fslide_0.jpg%3F21716780)
質とスピード(2022春版、質疑応答用資料付き)
CircleCI に入って色々と面白いなぁって思いながら毎日楽しんでる。その楽しんでることのひとつに Git のブランチモデルがある。最初はびっくりしたけど、慣れるととても良い 最初に言っておくと、この手法がどこにでも当てはまるとは思ってない。業種や、開発形態、プロダクトのタイプなどによって合うやり方は違う。単に CircleCI には、この手法がとても合ってるなぁと思う トランクベースのブランチモデル タスクに着手するときは、まずメインブランチからそのタスク用のブランチを作る。develop ブランチや release ブランチみたいな長く生きてるブランチはない。そのタスク用のブランチにコミットをプッシュしたらプルリクエストを出す。そして、レビューが終わればメインブランチにマージされる。タスクに着手してからマージまで、はやければ1時間ぐらい。長くてもだいたい2,3日くらい そして、メイン
はじめに 10 年前の今日、2012/02/03 に Just Quick Search という iOS アプリをリリースした。 個人で開発を行い、100% すべての要素を自分で考え作り上げてきた。 今日はこのアプリに関する 10 年間の思い出と技術的な部分についてをアツく語りたいと思う。 アプリ紹介 Just Quick Search は検索補助アプリである。 このアプリを使うと普段 iPhone で行っている 検索 というアクションをほんの少しだけ 速く 実行できるようになる。 以下がキーワード iphone を検索している時の挙動だ。 ip と入力したところで候補に出てきた iphone をタップし、キーボード右下の search をタップすると Safari が立ち上がり Google での検索結果が表示されるというものである。 メインの機能はこれだけだ。 一見ただ検索をしているだ
ツイッターで偶然見かけたプロダクト開発に関する一連のツイートが、プロダクトチームと経営陣、あるいは開発メンバーやプロダクトマネジャーの間に起きる摩擦を見事に言語化していました。 As they grow in size, teams within megacorps and startups tend to implicitly bias more towards Project Thinking and not enough Product Thinking. Product Thinking is a mindset and a process that, once you see, you cannot unsee it. Product Thinking, Project Thinking, a thread: pic.twitter.com/rbY80wTVgE— Shreyas
[CEDEC 2021]フランス人開発者が,日本のゲーム業界の常識を斬る。「日本で世界規模の競争力のあるゲーム開発は可能なのか?」聴講レポート ライター:箭本進一 日本で活躍するフランス人開発者が,日本ゲーム業界の問題点を指摘するという講演「Is Worldwide Competitive Game Development possible in Japan?/日本で世界規模の競争力のあるゲーム開発は可能なのか?」が,ゲーム開発者向けカンファレンス,CEDEC 2021の2日目となる2021年8月25日に行われた。日本のゲーム業界が「マネジメント」「キャリア」「競争力」の3分野に抱える問題とは,どのようなものなのだろう? 「CEDEC 2021」公式サイト 講演を行うハンサリ・ギオーム氏は,東京に本拠を置くゲーム開発スタジオWizcorpのCEOを務めている。2006年に日本に住み始めて以
アジャイル開発をはじめて体験すると、いろいろな考え方を身につけるために苦労をすることがあります。 特に、相対見積もりや、ベロシティによる経験主義的な見通しの取り方について、実際に経験せずに理解するのは難しいようです。 そこで今日は、日常生活の中で馴染みの深い考え方を使って、説明を試みてみたいと思います。 「コース定数」でアジャイルな見積もりを考えてみる 国民的な娯楽である登山をやられる人なら誰もが知っている「コース定数」という考え方があります。みなさんもご存知かと思いますが、簡単に解説します。 山は、事前の計画がとても重要でありつつも、実際に登ってみないとコースの状態や、自分の体力がその山に適しているのかがわかりづらい遊びです。そういう意味では、経験主義的なアプローチが必要なソフトウェア開発に似ているとも言えます。 交通機関やレスキューの体制が整備されている街中と違い、山は自分の体がすべて
Your shopping website is not an SPA. I repeat: your shopping website is not an SPA. Stop trying to sculpt David with a JS chainsaw and get yourself an HTML/CSS chisel.— Alex Russell (@slightlylate) 2021年8月10日 この主張、界隈(少なくとも自分の観測範囲)では割とよく見かけるし、なんか定期的に話題になるトピックなのかなーと。 まあ持論としてもコレには概ね同意しており、会社のスタンスとも相まって、常日頃からぼんやり考えてたりすることでもある。 で、そんな折にこのツイートを発見して、さらにそれに言及してる人々を見て、ふと自分でも現状を整理しておきたいなーという気持ちになったので筆を執った次第。
久々に個人開発のはなしです. 昨年(2020)の話になりますが, 自分が気になる世の中のニュース(野球とかグルメとかいろいろ)だけをいい感じに集めてまとめて読みたい その中でも特に⚾, 速報とかいい感じに通知させたい ...という目的でデータ収集と通知の仕組みを自分用のプロダクトとして構築・運用をスタートしました. shinyorke.hatenablog.com 今年も上記のプロダクトをいい感じに運用しているのですが, 毎日見るのにGUIが欲しくなってきた 複数のデータソース(BigQuery, 生のCSV/JSON, Spreadsheet, etc...)を一つにまとめて見たい 毎日Slackなどに通知するようなモノもほしい という要望が出てきたので, これらの要望に応えるためRedashを使うことにしました. redash.io このエントリーでは, 個人開発に使える無料データ可視
アプレッソというベンチャー企業の CTO を務めて6年と2ヶ月になる。変化の激しいベンチャーに比較的長い期間身をおいていたので、社内外のいろいろなタイプのエンジニアと仕事をしてきた。 あるエンジニアが参加することで開発チームが短い期間で大きく変わったこともあったし、開発チームのメンバーが15人いた頃よりも、お互い補い合えるエンジニアが5人くらいの頃の方が成果が出たりすることもあった。 そういう経験を重ねていくにつれ、私の中では、スターエンジニアと呼べる人たちの持っているものについての、いくつかの類型ができてきている。今まで一緒に仕事をしていく中で本当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるような財務のわかるエンジニアとか営業もできるエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもなかった。ではどういうエンジニアが、というこ
社内でLTしたネタ。去年からサポートしているチーム作りのお話。 1週間スプリント 最初は短いサイクルで試行錯誤したいから1週間スプリントでやることにした。 スプリントの終了と開始 金曜日にスプリントレビューとレトロスペクティブとプランニング。 プランニングは2部制にして 第1部では次のスプリントでやりたいことの認識合わせを全員で 第2部では細かいタスクの話をエンジニア中心で やってる。 ストーリーポイントと理想時間を併用してみてる これはだいぶあとの方の話。 最初の頃はチケットのサイズを見積もるのにストーリーポイントだけを使ってたんだけど、半年くらいした頃にストーリーポイントに加えて理想時間の見積もりも併用することにした。 最初の頃に理想時間を導入しちゃうと、頭では分かってても「時間」に引っ張られてしまうので、ポイントだけで始めることにした。で、半年くらいしたころには新しいやり方にも慣れて
最近とあるサイトの新規リリースにかかわることができて,そこで得られた学びをフィードバックするという活動をやっている.具体的には運用で使えるIssue Templateを整備したりしているのだけれど,自分やチームの進捗管理みたいな分野でもフィードバックすることができたのでメモしておく. 毎日エンジニアMTGを開く 毎日Scrapboxに残タスク・進捗を書きチームで共有する 毎日の適当な時間を割いてMTGを開く MTGでやること 結果どうだったか 個人レベルの話 ページの内容 1日の流れ 終わり 毎日エンジニアMTGを開く スクラムっぽい話題?かもしれないけれど,自分のチーム(エンジニアは2人)の規模ではこれでうまくいった. 毎日Scrapboxに残タスク・進捗を書きチームで共有する 昨日からコピーしていく 毎日の適当な時間を割いてMTGを開く 話すことそんなになくても予定は作るしMTGは開く
現在の Android Developers の情報は非常に充実していて、Developer Guides を順に読み進んでいくだけで開発に必要な知識とGoogleが想定している(であろう)最も基本的な実装を学ぶことができる。 特にこの「基本的な実装」というものが重要で、これを知っておかないと開発者間の意思疎通がスムーズに行えなかったり、そもそも気をつけておくべき注意点を見落としがちになってしまう。 とはいえ、今の膨大な公式ドキュメントをただ読めというのは厳しいので、Android開発をする上で最低限理解しておいてほしい(と僕が思っている)事柄と、それについて知ることができるドキュメント類についてまとめてみることにする。 2018/03/25 : リリース周りについて別記事に追記した。 nein37.hatenablog.com 公式ドキュメントの重要ページ 公式ドキュメントと言った場合、
米Googleは12月8日(現地時間)、Androidアプリ向け統合開発環境(IDE)「Android Studio」のバージョン1.0正式版をリリースした。Windows、Mac、Linux向け正式版を無料でダウンロードできる。 ダウンロードには、IDE、最新SDK、Android 5.0 Lollipop、エミュレーター、Google APIなどが含まれる。 Android StudioはJava IDE「IntelliJ IDEA」をベースにAndroidアプリ開発に最適化したIDE。Googleは2013年5月のGoogle I/OでこのIDEのプレビュー版を公開した。正式版にはインテリジェントコード編集機能やユーザーインタフェース設計ツールなど、多数の新機能が追加された。
2013年に「リーン・スタートアップ」という書籍が出版されて、それからリーン (LEAN) という考え方に注目が集まるようになった。LEAN とは「無駄のない」とか「ぜいにくのない」とかそういう単語らしい。 書籍リーン・スタートアップには「スタートアップやその類が新しい事業を始めるときに普通にやってるとだいたい失敗するから、潜在顧客や顧客からのフィードバックをこまめに集めて軌道修正しながらゴールを見極めるやり方が良い」とか、雑にまとめるとそういうことが書いてる。 仮説を立ててフィードバックをもらって検証するということを短いイテレーションで繰り返す・・・というのを "フィードバックループ" と呼んでいて、それを細かくやる場合、製品を作り込んでからフィードバックをもらうのでは遅いし、例えばペーパープロトタイプをするとかそういう実験的なことで欲しいフィードバックが得られるならそれが一番いい ─
はじめに 2014年8月11日の晩に放送されたソニックガーデンのweb勉強会、SonicGardn Studyでは「いつまでクソコードを書き続けるの? 〜出来るプログラマだけが知っているコードレビュー7つの秘訣〜」というタイトルで、弊社ソニックガーデンの西見さん(@mah_lab)が講演してくれました。 デキるプログラマだけが知っているコードレビュー7つの秘訣 from Masahiro Nishimi いつまでクソコードを書き続けるの? 〜出来るプログラマだけが知っているコードレビュー7つの秘訣〜 - YouTube この放送の中でも触れられていたように、ソニックガーデンではコードレビューを大事にしています。 ただ、勉強会のスライドの中では具体的なコード例や指摘の例がほとんど出てこなかったので、「実際どんな感じなの?」という疑問を持った方もいたんじゃないかと思います。 そこで今回は「入社
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 デメテルの法則 別名最小知識の法則。デメテルは、豊穣の女神。アスペクト指向などの研究であった「デメテルプロジェクト」に由来。 基本的な考え方は、任意のオブジェクトが自分以外(サブコンポーネント含む)の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。 単純化して説明すると、オブジェクトの"メンバーのプロパテ
少し前の話ですが、Facebook CEOのマーク・ザッカーバーグ氏の発言が話題となりました。2012年9月11日に行われた米TechCrunchのイベントで同氏は、モバイル端末向けアプリを提供するプラットフォームとしてHTML5に賭けたのは同社始まって以来の戦略上最大の失敗だった、と発言したのです。 TechCrunch Disrupt SF 2012で話すマーク・ザッカーバーグ氏 ネイティブかHTML5かという対立軸 モバイルアプリの世界では現在、「ネイティブアプリか、HTML5か」という構図で技術が語られることが少なくありません。実際、両者には一長一短があり、ケース・バイ・ケースで使い分けられています。機能面や応答性ではネイティブアプリが有利ですが、HTMLを取り巻く開発環境は急速に進化していて、中長期的にはHTML5の普及が進むと見るのが一般的です。それだけに、ザッカーバーグ氏の発
2019/06/11追記: これは2012年の投稿です。なぜかはてなブックマークで拡散されていますが、内容は時代にそぐわなくなったものもあるのでご注意ください。 これ知らないプログラマって損してんなって思う汎用的なツールのコメントに寄せられたツールを分類分けしてみました。 解説は、ほぼコメントに寄せられた内容のコピペです。 URLのみの記述は公式サイト(か、ほぼ公式サイトと化しているサイト) 公式サイトとは別に、ページタイトルだけでツールを説明しきっているページへのリンクも付けておきました。類似ページが複数ある場合は、はてブのブックマーク数が多いものを選びました。 知らないツールもあるので、分類がいいかげんなところもあると思います。何か気づいたらコメントください。 解説が不十分なツールについても、補足(コピペで本文に取り込める体裁だとありがたい)を頂けると助かります! 元ネタの投稿は現在進
自動改札機の運賃計算プログラムはいかにデバッグされているのか? 10の40乗という運賃パターンのテスト方法を開発者が解説(中編) 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡山五郎氏の講演「自動改札機ソフトウェアの品質向上の取り組み 厳密な仕様、もらさないテストを目指して」。この記事では、そのダイジェストを紹介しています。 本記事は、前編、中編、後編の3部構成です。いまお読みのページは中編です。 自動改札機の制御は1000件くらいのテスト さて、次は間違えない自動改札機の話です。ここからソフトウェアの話になります。 1つは運賃計算。この切符はこの駅で降りられるのか、というもの。そしてもう1つは自動改札の制御。ランプを光らせるとか、切符を回収するとかです。 まずはその
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く