川峠 @eaglesakura 弊チーム、毎週水曜日を「進捗を出さない日」に制定。 サボっていたドキュメント作成や変わってしまった部分を追従したり、細かい糞コードを直したりする日とした。 川峠 @eaglesakura 愛車はcinelli/EXPERIENCE。 基本的にFlutterな人。「マルチプラットフォームのためのOpenGL ES入門」「初めてのOpenGL ES」他いろいろ書いてます。 eaglesakura.hatenablog.com
はじめに 規模の大小を問わず、レガシー化したサイトには色々な課題が存在します。課題の根本的な改善のためにソースコードをゼロから書き直してリニューアル(以後、このことをフルリニューアルと呼称します)するということは、とても魅力的な一方でリスクもあります。フルリニューアルすなわちアンチパターンとされていることも多いですね。ここでは「中規模程度のコミュニティサイトをフルリニューアル、すなわち一から全部作り直す」という選択をした背景や、その進め方について書いていきます。 なお、書きやすさのために筆者一人で思考・実行したように書いていますが、実際には事業部所属のもう一人のエンジニアもしくは二人の考えや行動をミックスしたものとなっています。 TL;DR PHP 5/Ethna & Smarty/オンプレ/オフショア開発7年ものを引き継ぎ/ツライ ↓ PHP 7/Laravel & Vue.js, El
TL;DR 企画力が…欲しい… pic.twitter.com/hJfr0qNv7T— ゆずたそ (@yuzutas0) 2020年11月19日 試行錯誤の瓦礫の記録です。 はじめに もくじ TL;DR はじめに もくじ 以前書いた記事 前提・免責 アイデア 1日1案(やってよかったこと) 1stスクリーニング(やってよかったこと) コミュニケーション チームへのリスペクト(やってよかったこと) 話す <<< 聞く(改善余地あり) 即決する(やってよかったこと) 自分で各論まで見る(やってよかったこと) 発散→収束でディスカッション(改善余地あり) イラストで話す(改善余地あり) 日次ミーティング(やってよかったこと) 議事録を書く(改善余地あり) 得た情報を共有する(改善余地あり) 想定納期を示す(改善余地あり) カレンダー招待&日程確約コメントを転記(改善余地あり) プロセス管理 仮説
世の中の受発注によるソフトウェア開発には、両極端がある。一つは、「誰もいない開発」。もう一つは、「おまとめしておきました開発」。 全員集合なのに「誰もいない開発」 「誰もいない開発」は、プロジェクトや開発の進め方をどうしていくべきか、誰一人考えられていない状況のこと。いろいろと「こうすべし」「ここが課題だ」と意見だけは出てくるが、主体的な行動が取られることは無い。 業を煮やした発注側の指摘も、受注側のテコ入れ人材の指摘も、会議で波紋は呼ぶが、少し揺れて消えていく。いずれにしても、行動に落ちていかないため、言葉として宙をしばらく漂うだけ。「前回のあれどうなった?」で場には、再び波紋が広がるが、大した結果には繋がらない。 結局は身をもって引っ張っていくような人物が出てくるまで、状況は変わらない。どれだけ発言があったとしても、行動に落とし込むまでは。言葉だけ重ねても状況は一歩も進んでいかない。
Founder Customer Fitこのセクションについて解決したい課題を見つけよう顧客を決めようリーンキャンバスを書こうミッションを決めようCustomer Problem Fitこのセクションについてペルソナを立てよう共感マップをつくろうカスタマージャーニーマップをつくろう課題仮説を整理しようプロブレムインタビューをしようProblem Solution FitこのセクションについてPEST分析をしようフックモデルを定義しようプロトタイプをつくろう解決策仮説を整理しようソリューションインタビューをしようSolution Product Fitこのセクションについて名前をつけようユーザーストーリーマップをつくろうMVPを構築しようMVP仮説を整理しようMVPインタビューをしようProduct Market Fitこのセクションについてグロースサイクルを定義しよう利用規約をつくろうプロ
学部 3, 4 年生向けの特別講義で『ウェブの進化とウェブブラウザ開発の最前線』というタイトルで話をしてきました。 ウェブの進化の歴史を知ることで現在のトレンドについて理解し、またウェブブラウザというグローバルで大規模なソフトウェアの開発の一端を垣間見ることで、ウェブやウェブブラウザの開発に少しでも興味を持ってくれたら良いなぁという気持ちで話をしてきました。 なお歴史観については私の事実誤認も含まれると思うので、間違いを見つけたら教えて下さい :-) 追記 (随時) たくさんの反応を頂きありがとうございます!次回同じような資料を作るときの参考にできるよう、ここにメモしていきます。ウェブは無限に話せる話題があって楽しいですね! ウェブ以前のハイパーテキストの歴史も取り入れるべきでは? ありがとうございます!おっしゃるとおりで、ウェブの進化史と言いつつウェブが公開されてからの話しかしていないの
発注者と開発者の認識の齟齬により要求と実現されるソフトとの間に「ギャップ」が生じます。具体的には、次の(1)~(3)のようなギャップが生じます。 要件定義すべき内容が抜けており、開発者に説明していない。 発注者が開発者に説明したが、何らかの理由で漏れた。 開発者が何らかの理由により誤認・拡大解釈し、実現範囲に取り込んでしまった。 機能要件に着目し、上流工程で実現したい情報システム像を伝え、発注者と開発者との不充分な合意形成が原因で発生する下流工程の手戻りを防止するための次のようなコツを集めたものです。 実現したい情報システム像について発注者と開発者が合意形成するために、伝える側が漏れなく正確に情報を提供するためのコツ 発注者と開発者との不充分な合意形成が原因で下流工程で発生する手戻りを防止するための先人の開発者のコツ 機能要件の合意形成ガイドは、「概要編」 と次の6つの技術領域のコツをまと
こんにちは! Tetsukick(菊池哲平)です。 2020年11月現在、インドネシア(PT.AQ Business Consulting Indonesia)でモバイルアプリ開発の技術顧問をしております。 iOS歴5年、Flutter歴1年。個人でもアプリ開発してます。 本記事の対象読者 モバイルアプリ開発者 Flutterの今後の可能性を知りたい方 モバイルアプリ開発案件を検討中で技術選定をされている方 本記事のタイトルが気になる方 序 今回インドネシアでモバイル開発の技術顧問をさせていただく中で、Flutterの提案から導入までを実施し、実際に導入に至ることができましたので、その過程で用いた技術的根拠等々をシェアいたします。 実際に非技術者に対しても提案をしましたので、そのままお使いいただくことも可能かと思います。 PPT素材が必要な方いましたらTwitter_@tpi29までDMい
ソフトウェアテストシンポジウム 2020 新潟 JaSST'20 Niigata 基調講演 2020年9月28日(月) http://www.jasst.jp/symposium/jasst20niigata.html
こんにちは。コネクト支援チームの@tignyaxです。 みなさま、夏はどう過ごされたでしょうか? 私は、夏が好きなのに今年は夏らしいことが出来なくて寂しいなぁとなっています。。。 さて、今年2020年もエンジニア新人研修を行いましたので、その紹介と講義資料を公開いたします。 2020年のエンジニア新人研修について 基本的には2019年と同じ形*1での実施となりました。 最初の1週間で必修講義をしたあと、新人の皆さんには2週間ずつ3チームを体験してもらいました。 チーム体験のコンセプトは、新人に「興味のあるチームで実際に業務を体験し、配属希望を決める参考になった。」と言ってもらうことです。 各チーム体験では座学や研修を中心にするのではなく、業務体験が中心です。 チーム体験を通して、配属先を検討する材料にしたり、いろんなチーム/人/業務を知ってもらえる機会となります。 必修講義 誰に: 開発/
2016年2月末、スクウェア・エニックスを離脱して数か月になり、これまで伝えられなかった事もお話しできる立場になりました。 証券時代16年、ゲーム時代16年と、気がつけば中々の古参。 改めて見渡すと、アーケードゲーム、家庭用ゲーム、PC、スマホゲームと全ての時代を経験し、かつグローバル展開を行っていた方がほとんどいらっしゃらない事に気づきました。 またこの間、経営者として、業界リーダーとして、数々の貴重な局面に立ち会っています。 事実を忘れてしまったり、自分の都合のいいように記憶を塗り替える前に、皆さんにお話しする意味があると思いました。 経営者は、その足跡について1ミリ単位で説明できなければならないというのが、私の持論です。 無論、その時々の事実認識には個体差はあるでしょう。また、戦略実行にあたっては、様々な方が関わりますから、各人の視点によって、同じ事実でも見え方は異なるでしょう。さら
Intro Web の https 化が進み、それに伴って https を前提とする API も増えてきた。 そうした API を用いた開発をローカルで行う場合、 localhost という特別なホストを用いることもできるが、それだけでは間に合わないケースも少なからずある。 localhost を https にするという方法もあるが、そのように紹介されている方法には、いくつか注意すべき点もある。 この辺りの話を、直近 1 ヶ月で 3 回くらいしたので、筆者が普段使っている方法や注意点についてまとめる。 特に推奨するつもりはない。 Update chrome の --host-rules について追記 localhost での開発の注意点 例として https://example.com にデプロイする予定の ServiceWorker を用いたアプリがあったとする。 開発をローカルで行う
ソフトウェアシステムでは、クラフト(出来の悪いもの)が生まれやすい。システムの修正や拡張をしようとしても、内部品質の欠如がそれを難しくしている。「技術的負債」とは、Ward Cunninghamが作ったメタファーである。ファイナンスの負債のように考えることで、こうしたクラフトの扱いのことを考えやすくなる。たとえば、新機能の追加にかかる余分な労力は、負債の返済にかかる利子である。 あらゆるソフトウェアシステムには、タスクを実行するために必要とされる「本質的な」複雑さが一定量含まれている…… ……だが、ほとんどのシステムには「クラフト」が存在しており、理解を難しくしている。 クラフトがあると、変更するのに余分な労力がかかる。 技術的負債のメタファーは、こうしたクラフトを「負債」として扱う。変更に必要な余分な労力は、負債の利子の返済に相当する。 私のコードのモジュール構造が複雑だったとしよう。こ
システム開発の世界において「技術的負債(Technical Debt)」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham (ウォード・カニンガム)です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました("Shipping first time code is like going into debt")。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開
成功者がどのようにNew Relicを使用してKubernetesのパフォーマンスを4倍に向上させ、拡張性とスループットを改善したかをご覧ください。
厚生労働省は現在、新型コロナウィルス感染症(COVID-19)の“感染が疑われる濃厚接触”を通知する「接触確認アプリ」の開発を進めている。 開発を受注したのは日本国内のベンダー。一部で「米マイクロソフトが受注した」と報道されたが、これは間違いだ。とは言え、マイクロソフトが無関係というわけではない。そこには多少事情がある。 実は、日本で使われるアプリのベースとなる部分は、個人が中心となったボランティアベースのプロジェクトで、オープンソースとして開発されたものを利用している。 そのアプリは、なぜオープンソースで開発されたのか? そして、そこに人々はどう関わっているのか、開発にかかわった関係者を取材した。 接触確認アプリがどういうものか、おさらいしておこう。 接触確認アプリは、スマートフォンのBluetooth機能を使い「一定以上の長い時間、スマホを持っている人同士が近くにいた」情報を記録するア
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く