スクラムフェス福岡2024での講演資料です。 --- 皆さん、職場でFour Keysを導入していますか？ Yesと答えた皆さん、『LeanとDevOpsの科学』は読みましたか？ あくまで僕の周囲のみの観測で語るのですが、Four Keysを職場で導入しているという人はとても多いので…
スクラムフェス福岡2024での講演資料です。 --- 皆さん、職場でFour Keysを導入していますか？ Yesと答えた皆さん、『LeanとDevOpsの科学』は読みましたか？ あくまで僕の周囲のみの観測で語るのですが、Four Keysを職場で導入しているという人はとても多いので…
たまにLINEするくらいだった遠方の父67歳と僕。ITツール導入でコミュニケーションが劇的に変化した 公開日 | 2023/03/20 更新日 | 2023/03/20 地主恵亮 見守りツールというものがある。いろいろなパターンが考えられるけれど、今回は親の見守りツールの話だ。親が一人で離れたところに住んでいると、病気になっていないか、倒れていたらどうしよう……など何かと心配事が絶えない。またコミュニケーションがうまく取れないこともある。 LIFULL 介護が2021年に実施した「離れて暮らす親とのコミュニケーションに関する実態調査」を見ると、直接親と会えないことに不安を感じている人は50.9%と半数以上を占めている。私と同じような悩みを持っている人は多そうだ。 そこで今回は、見守りツールを通して遠方の親とコミュニケーションを取るおすすめの方法を詳しい人に聞こうと思う。 親も私も年を取る
本連載は、最新のソフトウェア開発の課題点を解決する手段であるフィーチャーフラグ（Feature Flag）について、概要や導入方法、ベストプラクティスを紹介します。第1回は、フィーチャーフラグとはなにか、どのようにしてプロダクト開発を変えていくのか、そのメリットと導入の際の懸念点を説明します。 はじめに 本連載はフィーチャーフラグについての連載です。最新のソフトウェア開発の課題点を解決する手段であるフィーチャーフラグに焦点をあて、フィーチャーフラグとは何なのか、どういった機能を提供するのか。フィーチャーフラグのメリット・デメリットを、具体例を使って詳細に説明します。また、導入前に考慮すべきことや、フィーチャーフラグの実装、サービスの選定の際の注意点、効率よく、かつ継続的に使用していくためのベストプラクティスも併せて解説します。さらにはサードパーティー製のフィーチャーフラグサービスの比較を行
「タイムゾーン呪いの書」は、もともと 2018年に Qiita に投稿した記事でしたが、大幅な改訂を 2021年におこない、同時にこちらの Zenn に引っ越すことにしました。 この改訂では Software Design 誌の 2018年 12月号に特集の一章として寄稿した内容も取り込みつつ、夏時間をめぐって各地で起きつつある変化について 2021年 6月現在の状況なども追加しました。そんな追記もしていたら記事全体が長大になってしまったため、この「知識編」と、「実装編」・「Java 編」に記事を分けました。「知識編」は、導入にあたる第一部です。 Qiita のほうは、引っ越した旨とこの引っ越し先へのリンクだけ追記して、しばらくそのまま残すつもりです。 はじめに タイムゾーンという概念のことは、ほとんどの人が聞いたことがあると思います。ソフトウェア・エンジニアでも多くの方が、時刻やタイムゾ
はじめに 専門家としてのアイデンティティ 分野の雰囲気の変化 コモディティ化と専門家の役割の低下 商業化・特許・ブラックボックス シェアの低下 計算資源の不足 新しい IT 技術を習得できない 小回りがきかない 同僚や分野の関心との乖離 他人事になってしまった 自分の存在意義を信じられない 今後の方針 可能性 1: 日本の電顕施設での解析支援とその問題 可能性 2: 電顕施設ではなく(生)化学系グループへ所属する 可能性 3: 仕事だと割り切って企業に行く おわりに 追記とコメント返信 変更履歴 はじめに 筆者*1は構造生物学(X 線回折と電子顕微鏡単粒子解析)のためのプログラム開発とデータ処理を専門としている。昨年、英国の研究機関にて任期なしの investigator scientist ポストに昇進し、Nature に筆頭著者として論文を出し、年間被引用数 1850 以上、h-ind
初めてまともに携わったシステムはNTT研究所で作られていたCBoCといわれるものであった。内容について詳しくは述べないが、国内では割と先進的でありながらとにかくNTTの事業会社（割と稼いでいる）で使えるものを作ろうというものであった。この時期は研究所は研究だけしていればよいというものではなく事業貢献が求められており、論文になるような研究を生み出すだけでなくそれをどうやってビジネスにするかが重要視されていたのだと思う。このとき作ったものは実際に事業会社で使われ、退職の前後には年間数万円が口座に振り込まれるようになっていた。なお収入なので税金の扱いを間違えないように。しかし特許といえばガッポガポ…というイメージだがそんなに当たることはない。わたしが携わったそのソフトウェアは確かに使われていたが、事業会社のビジネスの中核を支えていくようなものにはならなかった。ならなかったのでメンテナンスフェーズ
今回はソフトウェアエンジニアじゃない人や学生にも、ソフトウェアエンジニアという職業には夢があるかもしれないと思ってもらうために書いています。そのため既に詳しい方からすると回りくどい説明も多いと思いますがご容赦下さい。 基本的に記事とかには技術的なことしか書かないスタンスでやってきましたが、今回の件はさすがに誰かに伝えておくべきだろうということで長々と垂れ流しました。 概要 GW中に趣味で開発したソフトウェアを無料で公開したところAqua Securityという海外企業（アメリカとイスラエルが本社）から買収の申し出を受け、最終的に譲渡したという話です。さらに譲渡するだけでなく、Aqua Securityの社員として雇われて自分のソフトウェア開発を続けることになっています。つまり趣味でやっていたことを仕事として続けるということになります。 少なくとも自分の知る限り一個人で開発していたソフトウェ
ソフトウェアのテストはたいへんだなあ ソフトウェアのテスト、きちんとしてますか？最近は、スマートフォンやタブレットの普及に伴って、ユーザが使うデバイスの種類が多様化しています。 使われるOSやブラウザ、画面サイズの種類が増える中、プリキュア1の多様化も著しいですね。「プリキュアで学ぶワンライナーWebスクレイピング」で検証した通り、昨年までは43人、今年は「魔法つかいプリキュア」が加わることで、プリキュアの数は総勢45人になりました2。プリキュアはキャラクターによって専用デバイスを持ったり3、感情が昂ぶると常識を覆す事象を起こしたりするので、ITサービスを提供するエンジニアの方々は、ユーザ満足度向上のため、当然プリキュアがユーザになった場合も考慮した動作テストをされていると思います。 とはいえ、プラットフォームとプリキュアの組み合わせの数は、既にかなりの数です。全てのパターンを試すととても
Toyota Unintended Acceleration and the Big Bowl of “Spaghetti” Code | Safety Research & Strategies, Inc. O'Reilly Radar で知った記事だが、この記事自体は2013年、トヨタがオクラホマ州での急加速を巡る訴訟で和解した後に書かれたものである。 この記事で面白いのは、Michael Barr が20ヶ月以上にわたりトヨタ車で使われているソースコードを、Philip Koopman カーネギーメロン大学教授がトヨタのエンジニアリングの安全プロセスを精査した話で、両者ともトヨタのソフトウェアがスパゲッティコード山盛りなことを証言している。 トヨタの生産方式はアジャイル方面においてソフトウェア開発手法に多大な影響を与えている。ところでそのトヨタが開発するソフトウェアの品質はどうなんだ
ソフトウェアの負債というのは様々なかたちで存在している。技術的負債は広く知られているし、他の形態としては能力的負債とか品質的負債というものがある。ソフトウェアの負債はプロダクトの維持管理コストを増やし、開発者の気持ちを落ち込ませうるものだ。ソフトウェアの負債を扱うためにはいくつかの解決法がある。 Niklas Björnerstedt氏はブログ記事「技術的負債のその他いろいろ」の中で「能力的負債」に触れている。彼はこう定義する。 自分たちのコードベースにあるものと、そのうち実際に自分たちが理解しているものとのギャップ。 ソフトウェア維持管理の手間を低く保つためには、技術的負債と能力的負債のどちらにも注意を払わなくてはならないと、Niklas氏は説明する。 努力しないでいると技術的負債が時間とともに容赦なく増えるのとまさに同じで、能力的負債もまた時間とともに増えていきます。2種類の負債の大き
ソフトウェアの開発において、エラー処理は、時には本来の機能よりも重要です。業務として開発するソフトウェアでは、本来の処理を行うためのコードよりも、エラー処理のコードの方が量が多くなることも良くあります。 ところが、実際のソフトウェアの開発では、エラーをどこでどのように出力するかについては、実装者任せになってしまうことが多いようです。ソフトウェア設計書を見ても、エラーの出力については記述されていないことも良くあります。実装が終わってから、最後に慌しくエラーの出力を組み込むこともあります。 エラー処理について考えてみると、たくさんの難しい問題があることが分かります。これらの問題を理解した上で、きちんとエラー処理の仕組みを考えないと、ソフトウェアの設計や品質にも、重大な影響が及ぶかもしれません。 エラー処理とログ出力は、本来、どのようにして行うべきなのでしょうか。 エラーを知らせる仕組み ソフト
uptimeはnode.jsで作られたWebサーバ死活チェッカーです。 Webサーバがきちんと正常に動き続けているかどうか一番簡単にチェックするのは定期的にアクセスしてレスポンスタイムを見ることです。そんなWebサービスの死活チェックに使えるのがuptimeです。 サーバを立ち上げました。最初に監視するWebサーバを設定します。 URLと監視する間隔を指定するくらいです。 監視を開始しました。グラフは自動更新されないのでご注意ください。 イベントがあればこちらに出力されます。 グラフではなく一覧で結果を確認できます。 徐々にグラフが更新されていきます。 uptimeは1000以上のWebサーバを一括で監視できるパフォーマンスを持っています。またダウンしている際にはWebアラートを表示できます。エラーがあった際にはHTTPステータスやその内容を記録してくれます。サーバはタグを使ってグループ管
米スタンフォード大学が「テクノロジー起業」「SaaSのためのソフトウェア工学」「ヒトとコンピュータの対話」など無償オンラインの新講座を2012年1月から開始 米スタンフォード大学は、来年1月と2月に新しく開講するコンピュータ関連のオンライン講座について申し込みを開始しました。誰でも無料で受講できます。 新講座には魅力的なタイトルがずらりと並んでいます。例えばスタートアップに興味がある方には「Technology Entrepreneurship」や「The Lean Launchpad」などの講座に申し込みたくなるでしょうし、「Software Engineering for Software as a Service」の講座ではRuby on Railsでアジャイル開発を教えるというのですから、クラウドの開発者でなくとも興味がわくのではないでしょうか。 さらに、「Human-Comput
同僚とContinuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))の読書会をやっている。 英語の本なので、一人で読むにはちょっと敷居が高くても何人かで読めばどうにかこうにか読了できるような気がする。きっかけとして読書会というのはいいメソッドである。 読書会のメリットは、わたしのようなものぐさでもある種のプレッシャーがかかるので、どうにかこうにか続けられるというのがあるが、それ以外でもいろいろある。 何といっても読書会のメンバー間では、言葉の定義というか概念について共通の理解が深まる。 前回レガシーコード改善ガイドを読んだとき、レガシーコードというのは、テストのないコードのことを言
Primeはハードウェア構成やソフトウェアも含めたネットワーク図を作成するソフトウェア。 PrimeはJava製のオープンソース・ソフトウェア。システム開発を行う際にデスクトップやルータ、サーバ等の配置を図に起こす時は多い。そういう時にドローソフトウェアとしてMS Visioを使うケースが多いのではないだろうか。他にも類似ソフトウェアはあるが、アイコンがどうも好きではなく結局Visioを使っていた。 描画中 しかしネットワーク図を描くためだけにMS Visioを購入するのではあまりにも勿体ない。デザインに優れたソフトウェアがあればそれを使えるはずだ。そこでネットワーク図を描く際にお勧めしたいのがPrimeだ。 Primeはデスクトップやサーバ、ネットワーク機器を配置してそれらを線で結んでネットワーク図を作成するソフトウェアだ。端末間の接続法をRJ45またはUSBから選べるなど芸が細かい。さ
「ソフトウェア見積り」を読んだ後に「アジャイルな見積りと計画づくり」を読み直したら、とても理解しやすかった。 理解できたことをメモ。 間違っていたら後で直す。 ※追記：一部修正した。 ※追記：Velocityの計算方法を「塹壕よりScrumとXP」から参照するようにした。 【元ネタ】 Twitter / @akipii: 見積について色々考えている。1.0MD(人日)という単位は規模・出来高・工数という複数の意味を持ち混乱しやすいから、ソフトウェア開発の計画づくりに支障をきたしているのではないかという仮説を考えている。その考えを深めるとScrumのストーリーポイントはよく考えられた概念だと思う。 アジャイルサムライで一番難しくて面白い概念～Velocity: プログラマの思索 ソフトウェア開発に特有な技術～ソフトウェア見積り: プログラマの思索 チームは加速するのか～Velocityの使い
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
