タグ

ソフトウェアに関するorenonihongogayabaiのブックマーク (18)

  • 『LeanとDevOpsの科学』をきちんと解読する 〜Four Keys だけじゃ絶対もったいなくなる話〜

    スクラムフェス福岡2024での講演資料です。 --- 皆さん、職場でFour Keysを導入していますか? Yesと答えた皆さん、『LeanとDevOpsの科学』は読みましたか? あくまで僕の周囲のみの観測で語るのですが、Four Keysを職場で導入しているという人はとても多いのですが、そのうち、出典である『LeanとDevOpsの科学』をきちんと読んだ人はかなり少ないようです。 そして、ここで敢えて強めの主張をするのですが 『LeanとDevOpsの科学』を読まずにFour Keysをきちんと利用することはほぼ不可能です。 Forsgrenらは徹底した研究の結果として4つのメトリクス(指標)を見出すのですが、その裏には彼女らの沢山の思いが詰まっています。その思いや彼女らの思考を理解し、彼女らの考えをきちんとトレースして始めて、Four Keysは意味を持ちます。 そして『LeanとDe

    『LeanとDevOpsの科学』をきちんと解読する 〜Four Keys だけじゃ絶対もったいなくなる話〜
  • たまにLINEするくらいだった遠方の父67歳と僕。ITツール導入でコミュニケーションが劇的に変化した|tayorini by LIFULL介護

    たまにLINEするくらいだった遠方の父67歳と僕。ITツール導入でコミュニケーションが劇的に変化した 公開日 | 2023/03/20 更新日 | 2023/03/20 地主恵亮 見守りツールというものがある。いろいろなパターンが考えられるけれど、今回は親の見守りツールの話だ。親が一人で離れたところに住んでいると、病気になっていないか、倒れていたらどうしよう……など何かと心配事が絶えない。またコミュニケーションがうまく取れないこともある。 LIFULL 介護が2021年に実施した「離れて暮らす親とのコミュニケーションに関する実態調査」を見ると、直接親と会えないことに不安を感じている人は50.9%と半数以上を占めている。私と同じような悩みを持っている人は多そうだ。 そこで今回は、見守りツールを通して遠方の親とコミュニケーションを取るおすすめの方法を詳しい人に聞こうと思う。 親も私も年を取る

    たまにLINEするくらいだった遠方の父67歳と僕。ITツール導入でコミュニケーションが劇的に変化した|tayorini by LIFULL介護
  • フィーチャーフラグ(Feature Flag)はなぜ必要なのか?

    連載は、最新のソフトウェア開発の課題点を解決する手段であるフィーチャーフラグ(Feature Flag)について、概要や導入方法、ベストプラクティスを紹介します。第1回は、フィーチャーフラグとはなにか、どのようにしてプロダクト開発を変えていくのか、そのメリットと導入の際の懸念点を説明します。 はじめに 連載はフィーチャーフラグについての連載です。最新のソフトウェア開発の課題点を解決する手段であるフィーチャーフラグに焦点をあて、フィーチャーフラグとは何なのか、どういった機能を提供するのか。フィーチャーフラグのメリット・デメリットを、具体例を使って詳細に説明します。また、導入前に考慮すべきことや、フィーチャーフラグの実装、サービスの選定の際の注意点、効率よく、かつ継続的に使用していくためのベストプラクティスも併せて解説します。さらにはサードパーティー製のフィーチャーフラグサービスの比較を行

    フィーチャーフラグ(Feature Flag)はなぜ必要なのか?
  • タイムゾーン呪いの書 (知識編)

    「タイムゾーン呪いの書」は、もともと 2018年に Qiita に投稿した記事でしたが、大幅な改訂を 2021年におこない、同時にこちらの Zenn に引っ越すことにしました。 この改訂では Software Design 誌の 2018年 12月号に特集の一章として寄稿した内容も取り込みつつ、夏時間をめぐって各地で起きつつある変化について 2021年 6月現在の状況なども追加しました。そんな追記もしていたら記事全体が長大になってしまったため、この「知識編」と、「実装編」・「Java 編」に記事を分けました。「知識編」は、導入にあたる第一部です。 Qiita のほうは、引っ越した旨とこの引っ越し先へのリンクだけ追記して、しばらくそのまま残すつもりです。 はじめに タイムゾーンという概念のことは、ほとんどの人が聞いたことがあると思います。ソフトウェア・エンジニアでも多くの方が、時刻やタイムゾ

    タイムゾーン呪いの書 (知識編)
  • Nature に筆頭で出して、英国でパーマネントの職も得たけど、やりがいがなくなったので辞めます - biochem_fanのブログ

    はじめに 専門家としてのアイデンティティ 分野の雰囲気の変化 コモディティ化と専門家の役割の低下 商業化・特許・ブラックボックス シェアの低下 計算資源の不足 新しい IT 技術を習得できない 小回りがきかない 同僚や分野の関心との乖離 他人事になってしまった 自分の存在意義を信じられない 今後の方針 可能性 1: 日の電顕施設での解析支援とその問題 可能性 2: 電顕施設ではなく(生)化学系グループへ所属する 可能性 3: 仕事だと割り切って企業に行く おわりに 追記とコメント返信 変更履歴 はじめに 筆者*1は構造生物学(X 線回折と電子顕微鏡単粒子解析)のためのプログラム開発とデータ処理を専門としている。昨年、英国の研究機関にて任期なしの investigator scientist ポストに昇進し、Nature に筆頭著者として論文を出し、年間被引用数 1850 以上、h-ind

    Nature に筆頭で出して、英国でパーマネントの職も得たけど、やりがいがなくなったので辞めます - biochem_fanのブログ
  • コードを書いて金を稼ぐ - kuenishi's blog

    初めてまともに携わったシステムはNTT研究所で作られていたCBoCといわれるものであった。内容について詳しくは述べないが、国内では割と先進的でありながらとにかくNTTの事業会社(割と稼いでいる)で使えるものを作ろうというものであった。この時期は研究所は研究だけしていればよいというものではなく事業貢献が求められており、論文になるような研究を生み出すだけでなくそれをどうやってビジネスにするかが重要視されていたのだと思う。このとき作ったものは実際に事業会社で使われ、退職の前後には年間数万円が口座に振り込まれるようになっていた。なお収入なので税金の扱いを間違えないように。しかし特許といえばガッポガポ…というイメージだがそんなに当たることはない。わたしが携わったそのソフトウェアは確かに使われていたが、事業会社のビジネスの中核を支えていくようなものにはならなかった。ならなかったのでメンテナンスフェーズ

    コードを書いて金を稼ぐ - kuenishi's blog
  • 趣味で作ったソフトウェアが海外企業に買われるまでの話 - knqyf263's blog

    今回はソフトウェアエンジニアじゃない人や学生にも、ソフトウェアエンジニアという職業には夢があるかもしれないと思ってもらうために書いています。そのため既に詳しい方からすると回りくどい説明も多いと思いますがご容赦下さい。 基的に記事とかには技術的なことしか書かないスタンスでやってきましたが、今回の件はさすがに誰かに伝えておくべきだろうということで長々と垂れ流しました。 概要 GW中に趣味で開発したソフトウェアを無料で公開したところAqua Securityという海外企業(アメリカとイスラエルが社)から買収の申し出を受け、最終的に譲渡したという話です。さらに譲渡するだけでなく、Aqua Securityの社員として雇われて自分のソフトウェア開発を続けることになっています。つまり趣味でやっていたことを仕事として続けるということになります。 少なくとも自分の知る限り一個人で開発していたソフトウェ

    趣味で作ったソフトウェアが海外企業に買われるまでの話 - knqyf263's blog
  • テストの数を減らそう!プリキュアで学ぶPICT - Qiita

    ソフトウェアのテストはたいへんだなあ ソフトウェアのテスト、きちんとしてますか?最近は、スマートフォンやタブレットの普及に伴って、ユーザが使うデバイスの種類が多様化しています。 使われるOSやブラウザ、画面サイズの種類が増える中、プリキュア1の多様化も著しいですね。「プリキュアで学ぶワンライナーWebスクレイピング」で検証した通り、昨年までは43人、今年は「魔法つかいプリキュア」が加わることで、プリキュアの数は総勢45人になりました2。プリキュアはキャラクターによって専用デバイスを持ったり3、感情が昂ぶると常識を覆す事象を起こしたりするので、ITサービスを提供するエンジニアの方々は、ユーザ満足度向上のため、当然プリキュアがユーザになった場合も考慮した動作テストをされていると思います。 とはいえ、プラットフォームとプリキュアの組み合わせの数は、既にかなりの数です。全てのパターンを試すととても

    テストの数を減らそう!プリキュアで学ぶPICT - Qiita
    orenonihongogayabai
    orenonihongogayabai 2016/11/16
    あふれ出る注意事項の数にプリキュア境界値警察もにっこり。なおキュアモフルンの扱いが諸々めんどくさそう。mixinというより多重継承の神クラスっぽいのでリファクタリ(ry
  • トヨタの車のソースコードはスパゲッティコード山盛り? - YAMDAS現更新履歴

    Toyota Unintended Acceleration and the Big Bowl of “Spaghetti” Code | Safety Research & Strategies, Inc. O'Reilly Radar で知った記事だが、この記事自体は2013年、トヨタがオクラホマ州での急加速を巡る訴訟で和解した後に書かれたものである。 この記事で面白いのは、Michael Barr が20ヶ月以上にわたりトヨタ車で使われているソースコードを、Philip Koopman カーネギーメロン大学教授がトヨタエンジニアリングの安全プロセスを精査した話で、両者ともトヨタのソフトウェアがスパゲッティコード山盛りなことを証言している。 トヨタの生産方式はアジャイル方面においてソフトウェア開発手法に多大な影響を与えている。ところでそのトヨタが開発するソフトウェアの品質はどうなんだ

    トヨタの車のソースコードはスパゲッティコード山盛り? - YAMDAS現更新履歴
    orenonihongogayabai
    orenonihongogayabai 2015/06/04
    グローバル変数がカンバン方式だったのか/どうキレイに書いても10万行を超えるソフトウェアに「汚コードが産業スパイ対策になる」というのは間違い。車でコレを言っちゃうと安全性軽視と捉えられかねないかと。
  • ソフトウェアの負債を扱う

    Rustが再評価される:エコシステムの現状と落とし穴 In this article, we share findings and insights about the Rust community and ecosystem and elaborate on the peculiarities and pitfalls of starting new projects with Rust or migrating to Rust from othe...

    ソフトウェアの負債を扱う
  • エラー処理とログ出力

    ソフトウェアの開発において、エラー処理は、時には来の機能よりも重要です。業務として開発するソフトウェアでは、来の処理を行うためのコードよりも、エラー処理のコードの方が量が多くなることも良くあります。 ところが、実際のソフトウェアの開発では、エラーをどこでどのように出力するかについては、実装者任せになってしまうことが多いようです。ソフトウェア設計書を見ても、エラーの出力については記述されていないことも良くあります。実装が終わってから、最後に慌しくエラーの出力を組み込むこともあります。 エラー処理について考えてみると、たくさんの難しい問題があることが分かります。これらの問題を理解した上で、きちんとエラー処理の仕組みを考えないと、ソフトウェアの設計や品質にも、重大な影響が及ぶかもしれません。 エラー処理とログ出力は、来、どのようにして行うべきなのでしょうか。 エラーを知らせる仕組み ソフト

  • The Omni Group — creators of Mac, iPad, and iPhone productivity apps

    Meet the Omni Productivity Suite Tools as powerful as you Design, plan, organize, and execute like a pro OmniFocus is powerful task management software for busy professionals. With tools to help tame the chaos, you can focus on the right tasks at the right time.

    The Omni Group — creators of Mac, iPad, and iPhone productivity apps
  • 1,000のサーバでも監視できるnode.js製死活チェッカー·uptime MOONGIFT

    uptimeはnode.jsで作られたWebサーバ死活チェッカーです。 Webサーバがきちんと正常に動き続けているかどうか一番簡単にチェックするのは定期的にアクセスしてレスポンスタイムを見ることです。そんなWebサービスの死活チェックに使えるのがuptimeです。 サーバを立ち上げました。最初に監視するWebサーバを設定します。 URLと監視する間隔を指定するくらいです。 監視を開始しました。グラフは自動更新されないのでご注意ください。 イベントがあればこちらに出力されます。 グラフではなく一覧で結果を確認できます。 徐々にグラフが更新されていきます。 uptimeは1000以上のWebサーバを一括で監視できるパフォーマンスを持っています。またダウンしている際にはWebアラートを表示できます。エラーがあった際にはHTTPステータスやその内容を記録してくれます。サーバはタグを使ってグループ管

  • 米スタンフォード大学が「テクノロジー起業」「SaaSのためのソフトウェア工学」「ヒトとコンピュータの対話」など無償オンラインの新講座を2012年1月から開始

    米スタンフォード大学が「テクノロジー起業」「SaaSのためのソフトウェア工学」「ヒトとコンピュータの対話」など無償オンラインの新講座を2012年1月から開始 米スタンフォード大学は、来年1月と2月に新しく開講するコンピュータ関連のオンライン講座について申し込みを開始しました。誰でも無料で受講できます。 新講座には魅力的なタイトルがずらりと並んでいます。例えばスタートアップに興味がある方には「Technology Entrepreneurship」や「The Lean Launchpad」などの講座に申し込みたくなるでしょうし、「Software Engineering for Software as a Service」の講座ではRuby on Railsアジャイル開発を教えるというのですから、クラウドの開発者でなくとも興味がわくのではないでしょうか。 さらに、「Human-Comput

    米スタンフォード大学が「テクノロジー起業」「SaaSのためのソフトウェア工学」「ヒトとコンピュータの対話」など無償オンラインの新講座を2012年1月から開始
  • 分散リポジトリ型時代のソフトウェア構成管理

    正式には、 「ソフトウェア構成管理」 (Software Configuration Management: SCM) と言います。 「ラショナル統一プロセス」 (Rational Unified Process: RUP) では、 「構成および変更管理」 (Configuration and Change Management: CCM) などとも呼ばれます。 では「構成」とはなんでしょう?

  • Continuous Deliveryを読む。2011-11-06 - 未来のいつか/hyoshiokの日記

    同僚とContinuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))の読書会をやっている。 英語なので、一人で読むにはちょっと敷居が高くても何人かで読めばどうにかこうにか読了できるような気がする。きっかけとして読書会というのはいいメソッドである。 読書会のメリットは、わたしのようなものぐさでもある種のプレッシャーがかかるので、どうにかこうにか続けられるというのがあるが、それ以外でもいろいろある。 何といっても読書会のメンバー間では、言葉の定義というか概念について共通の理解が深まる。 前回レガシーコード改善ガイドを読んだとき、レガシーコードというのは、テストのないコードのことを言

  • これでVisioを使ったネットワーク図作成からおさらば?運用まで管理できる·Prime MOONGIFT

    Primeはハードウェア構成やソフトウェアも含めたネットワーク図を作成するソフトウェア。 PrimeはJava製のオープンソース・ソフトウェア。システム開発を行う際にデスクトップやルータ、サーバ等の配置を図に起こす時は多い。そういう時にドローソフトウェアとしてMS Visioを使うケースが多いのではないだろうか。他にも類似ソフトウェアはあるが、アイコンがどうも好きではなく結局Visioを使っていた。 描画中 しかしネットワーク図を描くためだけにMS Visioを購入するのではあまりにも勿体ない。デザインに優れたソフトウェアがあればそれを使えるはずだ。そこでネットワーク図を描く際にお勧めしたいのがPrimeだ。 Primeはデスクトップやサーバ、ネットワーク機器を配置してそれらを線で結んでネットワーク図を作成するソフトウェアだ。端末間の接続法をRJ45またはUSBから選べるなど芸が細かい。さ

  • 工数見積もりで陥りやすい罠 - プログラマの思索

    「ソフトウェア見積り」を読んだ後に「アジャイルな見積りと計画づくり」を読み直したら、とても理解しやすかった。 理解できたことをメモ。 間違っていたら後で直す。 ※追記:一部修正した。 ※追記:Velocityの計算方法を「塹壕よりScrumとXP」から参照するようにした。 【元ネタ】 Twitter / @akipii: 見積について色々考えている。1.0MD(人日)という単位は規模・出来高・工数という複数の意味を持ち混乱しやすいから、ソフトウェア開発の計画づくりに支障をきたしているのではないかという仮説を考えている。その考えを深めるとScrumのストーリーポイントはよく考えられた概念だと思う。 アジャイルサムライで一番難しくて面白い概念~Velocity: プログラマの思索 ソフトウェア開発に特有な技術~ソフトウェア見積り: プログラマの思索 チームは加速するのか~Velocityの使い

    工数見積もりで陥りやすい罠 - プログラマの思索
  • 1