タグ

2021年8月2日のブックマーク (30件)

  • AI倫理を考える その2~アシモフ作品と「ロボット工学の三原則」を題材に~ - データデザイン(富士通クラウドテクノロジーズ)

  • https://www.ipa.go.jp/archive/files/000065172.pdf

  • 日本産業標準調査会:国際協議・協力-WTO/TBT

    WTO/TBT TBT協定について TBT協定とは、1979年4月に国際協定として合意されたGATTスタンダード・コードが1994年5月にTBT協定として改訂合意され、1995年1月にWTO協定に包含されたものです。TBT協定はWTO設立協定と一括受託の対象の協定となっており、WTO加盟国全部に適用されるものとなっています。 TBT協定は、工業品等の各国の規格及び規格の適合性評価手続が国際貿易に不必要な障害(貿易の技術的障害: Technical Barriers to Trade)をもたらすことのないよう、国際規格を基礎とした規格制定の原則、規格制定の透明性の確保等を規定しています。これによって、規制や規格が各国で異なることにより、産品の国際貿易が必要以上に妨げられることをできるだけなくそうとしています。 具体的には、加盟国に対して、強制規格、任意規格及び適合性評価手続について、内国民待

  • レビューの工夫 - Qiita

    ソースコードレビューなど、設計審査(design review)は製造業、IT業界でも重要です。 Reviewerの能力 製造業とIT業界で大きな違いを感じるのは、Reviewerの能力の管理形態です。 製造業では、どの製品、どの技術を検討する場合には、誰と、誰と、誰の入った設計審査が必要だとすることがある。 IT業界でも、言語、OS、アプリの種類などで、その技術について、社内で最高の人を割りあてていることもある。 設計審査担当が超絶な人がいない場合には、納期、品質、費用の3人に分けて、それぞれの視点だけの意見をだすようにする方法もある。 IT業界でも、この人が見てなきゃ、出荷しちゃだめって、能力のある人を関門にしている場合があります。 その際に、なぜ、その人が見なきゃだめかの根拠を明示的に示していないことがあるような気がします。 オープンソース事業では、コードを書いた人の名前が残っており

    レビューの工夫 - Qiita
  • 分析の基礎 - Qiita

    分析と設計は対の概念であるという仮説を立てる。 設計するために分析するのと、設計を分析するのとは量と質とが総量では対等かもしれないという仮説を立てる。 分析の手法は大学ではほとんど教えていないし、 企業の新人教育でもほとんど教えていない。 分析で発達しているのは、 化学物質の分析と 安全分析。 まず、安全分析から手法に関する文献とその参考文献を記載する。 #ISO/IEC GUIDE 50:2014 Safety aspects — Guidelines for child safety in standards and other specifications https://www.iso.org/obp/ui/#iso:std:iso-iec:guide:50:en Bibliography [1] ISO 7000, Graphical symbols for use on equ

    分析の基礎 - Qiita
  • シェルスクリプトの互換性と生産性の問題を解決する高度なプログラミング技術 〜1万行のコードをメンテしつづけるのに必要なもの〜 - Qiita

    はじめに macOS で開発したシェルスクリプトが番環境の Linux で動かなかったという経験はないでしょうか?シリーズの第一弾で POSIX の問題点について解説しましたが根的な問題は POSIX コマンドに互換性がないからです。この問題は GNU Coreutils をインストールすることで解決することができますが、環境によっては必ずしもインストールできるとは限りません。そういう場合は自分の手で互換性問題を解決する必要があります。また他の人が書いたシェルスクリプトがメンテナンスできなくて困ったことはないでしょうか?それはある程度の大きさにも関わらずメンテナンス性を考慮した書き方をしていないからです。ソフトウェアは規模に応じた適切な書き方があります。ある程度の大きさのシェルスクリプトを使い捨てシェルスクリプトの書き方(ワンライナー多用で関数を使わないような書き方)の延長で書かないよ

    シェルスクリプトの互換性と生産性の問題を解決する高度なプログラミング技術 〜1万行のコードをメンテしつづけるのに必要なもの〜 - Qiita
  • 中~大規模シェルスクリプトのためのメンテナンス性の高いディレクトリ構造 - Qiita

    #!/bin/sh set -eu basedir="$(cd -- "$(dirname -- "$0")/.." && pwd)" libdir="$basedir/lib/project" . "$libdir/common.sh" func # common.sh で定義されている コマンドが bin ディレクトリ以下に直接配置されているのに対してライブラリが lib/project 以下となっている理由は /usr ディレクトリにインストールしたときに bin ディレクトリのコマンドは PATH を通すことでコマンド名だけで実行できるようにするものに対して、ライブラリは project ディレクトリがないと他のプロジェクトと名前がかぶってしまう可能性があるからです。(もちろんコマンドも既存のコマンドとかぶらない名前にする必要があります。) 補足ですが、実行可能ファイル名は pro

    中~大規模シェルスクリプトのためのメンテナンス性の高いディレクトリ構造 - Qiita
  • シェルスクリプトで文字列を置換するreplace_all関数を作りました(実はコーディングスタイルの解説) - Qiita

    はじめに タイトルのとおりですがシェルスクリプトで文字列を置換する replace_all 関数を作りました。一応テストはしているのですがまだ実戦投入はしていません。もしかしたら仕様変更するかもしれないしバグもあるかもしれませんありました、後日修正しますが、関数だけでも十分利用価値がある(例えば HTML エスケープなどもこの関数を使えばシェル依存することなく簡単に実装することができるはずです。)のと、これを題材に私のコーディングスタイルの解説をするのにちょうど良さそうだと思ったので記事として公開します。 ちなみに実は同等の関数は以前に作成しているのですが、今とコーディングスタイルが異なってるのと当時はいきあたりばったりで実装していたので再実装しています。近いうちに今使っている実装と置き換える予定ですがまだ十分テストが出来ていません。(Linux以外のOSでクリティカルな問題が発生しないこ

    シェルスクリプトで文字列を置換するreplace_all関数を作りました(実はコーディングスタイルの解説) - Qiita
  • 「@kazuo_reve ワークショップ「ソフトウェア開発におけるHAZOP入門」」の勧め or 進め方 - Qiita

    @kazuo_reve ワークショップ「ソフトウェア開発におけるHAZOP入門」の結果 「ワークショップ「ソフトウェア開発におけるHAZOP入門」の結果」の分類 を受けて書き始めた記事です。 <この項は書きかけです。順次追記します。> 目的 安全分析はじめ、分析をする際の抽象的な手法であるHAZOPを、他の手法と併せて利用できるようになる。 成果 実行する前に、個人and/or組織で、作業の目標を立てる。 例: これまでに想定していない事故、操作を一つ以上記録する。 災害時、非常事態など、複数の要因で機能しない場合の対策を想定する。 顧客、仕入れ先の大事だと思っていることを知り認識合わせを行う。 方法 やり方は、毎回、変更するのがよい。 人数、時間、経験者の密度・深さ、説明の範囲など、考えられるありとあらゆるもの・ことを変更してみる。 組織の都合で、一通り全員作業するまで、同じやり方で作業

    「@kazuo_reve ワークショップ「ソフトウェア開発におけるHAZOP入門」」の勧め or 進め方 - Qiita
  • 効率的なHAZOPの進め方。仮説(187) 安全(94) - Qiita

    効率的なHAZOPの進め方 HAZOPは安全なシステムを設計する際におこなうとよい分析手法です。 11の魔法の言葉(guide word)があります。 魔法の言葉(guide word) 無逆他大小類部早遅前後 大小類部が空間を 早遅前後が時間を 大小早遅が量を 類部前後が質を 大が上限を(類早前) 小が下限を(部遅後) HAZOPの利点 物にも事にも適用できる。 システムの状態を検査するプログラムを作成するのに、いろいろ役立つ道具です。 一人作業 最初に1人で作業します。 責任を持って作業 利用者視点は設計能力が高くなくても担当可(設計者との差が分る) 誘導語と図(設計図・外観等)を見てありえない事を「外れ」に列記 想定外(思わぬこと)に気付く 人に言うのは恥ずかしい事でも,自分で妄想するだけならいろいろ考えられる 最初に自分が考えたことが全体の表の中で残ってたり,統合されていくことによ

    効率的なHAZOPの進め方。仮説(187) 安全(94) - Qiita
  • ちょけねこ たんじょうびのおくりもの 安全(96)  - Qiita

    ちょけねこ たんじょうびのおくりもの プログラムの仕様・設計で抜け漏れがないかを確かめるために使うことができる道具の説明絵です。 誰もがわかるように、楽しいことで説明しています。 特に、10歳以下の子供が取り組むときには、必ず楽しいことで演習をしてください。 最後に、直接プログラムで判定できるように式を記述しています。プログラムを組む時の条件分岐にご利用ください。 <この項は書きかけです。順次追記します。> This article is not completed. I will add some words in order. しらべかた(how to check) C言語風 (like c programming language) ここでは、HAZOPをプログラミングで生かす場合に、「C言語の場合だったらどうだろう」 という視点で、プログラムの断片を記載しています。変数、配列、関

    ちょけねこ たんじょうびのおくりもの 安全(96)  - Qiita
  • amazon 殿堂入りNo1レビュアになるまで。仮説(102) - Qiita

    100人以上の事業で、品質保証、分析とともに、教育担当をした。 <この項は書きかけです。順次追記します。> This article is not completed. I will add some words in order. 複数の組織にまたがる事業で、どう人の能力を判定し、どう教育・訓練をし、どういう道具を利用し、その道具の演習をどう組織化するか。 能力判定の仕組みは、IEEのsafety assessorのskill表と、 その発想を元に国内で作られたETSSの2つを統合した表を作成した。 能力判定する自分の能力は誰が判定するか問題が残った。 資格と経験は網羅し、自分の資格と経験で不足する部分は、 事業内で優れた人を数人確保し、いざという時にに頼むことにした。 amazon.co.jp それだけでも不十分と判断し、amazon.co.jpに、reviewを3年間で1万冊あげ、

    amazon 殿堂入りNo1レビュアになるまで。仮説(102) - Qiita
  • 未経験者が認識してなさそうなTIPS - Qiita

    はじめに 自身の4年間を振り返って。 「認識していない」とはNull(あるいはEmptyやNothing)のようなものをイメージしています。 初心者が知ることによって、その技能Lvが0以上になるようなTIPSを目指して書きました。 ※筆者の4年振り返りの3部作 未経験から4年働きながら、読んでよかった読み物 未経験者が認識してなさそうなTIPS(当記事) 新卒後輩の扱いについてのTIPS 労働者として を読んで学ぶこと やはりが一番コスパ良い。 今の時代はAmazonレビューを見ることで、当たり外れも予測しやすい。 何度も読む or ランダムアクセスに読む or 古が安い → 紙が良い。 上記以外 → 電子書籍でも良い。 「未経験から4年働きながら、読んでよかった読み物」※筆者の別記事。 https://qiita.com/Nao9syu/items/0bedec7a749ab2d

    未経験者が認識してなさそうなTIPS - Qiita
  • プログラマにも読んでほしい「QC(2)検定にも役立つ!QCべからず集」OSEK(71) 統計(43) - Qiita

    QCの基はデータ解析。データ解析ばかりしていて、仕事に役立てない人をいっぱいみてきた。ある日、ある人の言葉から、筋書きを考えていたら、それ自分かもってなった。 データサイエンティストの気づき『勉強だけして仕事に役立てない人。大嫌い』それ自分かもってなった。 https://qiita.com/kaizen_nagoya/items/d85830d58d8dd7f71d07 OSEK OSを利用するにあたって、設計にあたっての証明と、HAZOPによる安全分析と、成果に対する品質測定を行ってきた。 QC検定にも役立つ! QCべからず集 https://bookmeter.com/books/4679281 すごく内容がよい。 プログラマの方にも読んで欲しいと思い、筆をとりました。 はじめに(introduction) 統計、確率を学べば、因果関係が大事なのではなく、時系列の推移が大事だとわか

    プログラマにも読んでほしい「QC(2)検定にも役立つ!QCべからず集」OSEK(71) 統計(43) - Qiita
  • プログラマがQC(10)検定を受ける意味・価値・課題 統計(86) - Qiita

    QC検定 という資格試験が有る。 https://webdesk.jsa.or.jp/common/W10K0500/index/qc/ 受かることの意味、価値、課題ではない。2021年春、みごと1級落ちました。報告。 https://webdesk.jsa.or.jp/common/W10K0500/index/qc/qc_pass/ 品質管理の知識を問う筆記試験を毎年2回、3月と9月に全国約120か所で実施しています。4段階のQCレベルによって企業人、学生などのキャリアアップ実現を支援しています。 4、3、2、1級と4段階ある。4級は中卒程度、3級は高卒程度、2級は工業大学卒業程度、1級が経験3年程度かもしれない。ここでは1級だけを対象にする。 1級は2、3、4級の範囲を含んでいることを想定しています。 実際には、2級と1級も過去問を買いました。 わかりにくさ 2 4回過去問を解いてみ

    プログラマがQC(10)検定を受ける意味・価値・課題 統計(86) - Qiita
  • 技術系メーリングリストで質問するときのパターン・ランゲージ

    目次 はじめに メーリングリスト —— サポートセンターではなく互助会です 表題 —— あいさつではなく用件を書きましょう 自己紹介 —— 自分の知識・技能・経験を簡潔に書きましょう 書き出し —— 最初に問題の要旨を書きましょう 肩書き —— 会社の名前を背負っていることを忘れないように 実行手順 —— 手順は箇条書きで書きましょう 結果の予想 —— 期待した結果を書きましょう 実際の結果 —— 実際に起きたことを書きましょう ステップ明記 —— どこからうまく行かなくなったかを書きましょう 実際の値 —— 条件を具体的に書きましょう エラーメッセージ —— 必ずコピー&ペーストしましょう 判断理由 —— そのように考えた理由を書きましょう 文献の引用 —— 読者の手間を省くように書きましょう ソース —— 関連する部分を抽出して示しましょう スレッド —— 関連する話題なら「返信」しま

  • State of DevOps Report 2021を日本語で解説 ーTeam Topologies Model、プラットフォームが重要な要素ー - TC3株式会社|GIG INNOVATED.

    State of DevOps Report 2021を日語で解説 ーTeam Topologies Model、プラットフォームが重要な要素ー はじめに State of DevOps ReportはDevOpsの成熟度についてアンケート形式で調査しているレポート資料です。毎年アップデートされているので、直近の動向などを理解し、かつ課題解決の活路を見出すのに良いレポートです。2021版が先日リリースされていました(もとのレポートはこちら)。 デジタルトランスフォーメーションの文脈の中で、ソフトウェア開発がますます増えてきていますが、単に一発作っておしまいではなく、継続的に進化させることが求められます。継続的にサービスを進化させていくことがビジネス力の根源となるということをアンケート調査から証明したのが、このレポートで、調査内容については、『LeanとDevOpsの科学』をご一読いただく

    State of DevOps Report 2021を日本語で解説 ーTeam Topologies Model、プラットフォームが重要な要素ー - TC3株式会社|GIG INNOVATED.
  • 3分でざっくりわかるスクラム(スクラム用語を使わないスクラムの説明)

    みなさんこんにちは。@ryuzeeです。今日は小ネタです。 3分くらいでスクラムをざっくり分かってもらうための説明を以前作ったのですが、意外と役に立っているのでブログで公開しておきます。 この記述については、CC BY-SA 4.0ライセンスとします。 クレジット表記(@ryuzee / Ryutaro Yoshiba)のもとで共有や派生物を作って構いません(その場合は元のライセンスを継承します)。 製品の目標や方向性、成果に責任を持つ人を1人決めます(=プロダクトオーナー)製品の目標や実現したいことを一覧にして、常に最新の状態にしておきます(=プロダクトバックログ)製品を作るのに必要な作業は色々な能力を持った開発者たちに任せます(デベロッパー)頻繁に動くものを見たほうが安心なので、固定の短い期間に区切って繰り返します(=スプリント)短い期間をうまく過ごして成果を出すには計画が必要です(=

    3分でざっくりわかるスクラム(スクラム用語を使わないスクラムの説明)
  • ミクシィGit研修 (21新卒)

    ミクシィGit研修 (21新卒) 1 shumon.fujita

    ミクシィGit研修 (21新卒)
  • 【図解】Dockerの全体像を理解する -中編- - Qiita

    この記事は何か イメージやコンテナなどの基からdocker-compose、docker-machine, docker swarmなどのDocker周りの様々な概念の全体像を整理して、Dockerの仕組みを理解するための記事 対象読者 ・Dockerって何? ・Dockerちょっと勉強したけどDocker compose? Docker machine? Docker Swarm? 色々ありすぎて意味不明 という方 中編では、「データマウント(volume), Docker Network, Docker Compose」 について書いて行きます。 前編はこちら ④ Dockerにおけるデータ管理 起動したコンテナ内で扱う動的なデータは、読み書き可能な最上レイヤー(コンテナレイヤー)に置くこともできますが、 ・コンテナが削除された時点でそのコンテナ内のデータは消える ・コンテナ間でデー

    【図解】Dockerの全体像を理解する -中編- - Qiita
  • 枝豆の調理時間と味の変化 | エンジニアのメソッド

    はじめに 枝豆は未成熟の大豆をべる作物です。うま味は豆の成長に欠かせないアミノ酸などの栄養素なので収穫後、すぐに調理する必要があります。 調理方法はフライパンで焼いたりホイル焼きにすると芳ばしさが引き立って美味しいと言われていますが、今回は最も一般的な茹でる調理法に着目して枝豆を美味しく茹でるための条件の整理から始めてみます。 美味しく茹でるための条件 枝豆の調理工程を細かく見ていきます。 枝豆は難しい工程はなく、次の3ステップで調理されます。それぞれ細かく見ていきます。

    枝豆の調理時間と味の変化 | エンジニアのメソッド
  • 非同期コミュニケーションにおけるドキュメント - CARTA TECH BLOG

    VOYAGE MARKETINGの @katzchum です。 自分が携わったプロジェクトで、以下の2点を課題として、プロジェクトの進め方について検討しました。 プロジェクト立ち上げの流動的な場面でもリモートのメンバーに対しても如何に早く共通理解を促進させることが出来るか? 開発のインプットとして、どうドキュメントを位置づけてチームへの情報の伝達手段として用いるか? 検討した結果、以下の取組を行ないました。 ドキュメントをDSLでコード化 DSLのレビューを通じて情報共有&ディスカッション デッドコード化させない取組(短期・長期ドキュメント) 取組のプロセスとして軽量だったわりには良い体験や気付きが得られた様に思い、プロジェクトの背景・初期の悩みから、どうアプローチして取り組んで行ったのか、振り返りも交えてお話したいと思います。 ドキュメントの悩み 新規のプロジェクト立ち上げ時にドキュメン

    非同期コミュニケーションにおけるドキュメント - CARTA TECH BLOG
  • 受け入れテストを日本語で書ける Jest 拡張 "Jest-gauge" を公開しました

    先日 Daniel North の記事を訳していて、この記事がドラフトのままになっているのを思い出したので、加筆して公開することにしました。 概要 Gauge のように受け入れテストを日語で書いて、 Jest を採用しているプロジェクトで受け入れテスト駆動開発 (ATDD) を実現できる Jest 拡張 "jest-gauge" を公開しました。 受け入れテスト駆動開発 (ATDD) とは 受け入れテスト駆動開発 (ATDD) とは、テスト駆動開発 (TDD) の延長線上にあるソフトウェア開発技法のひとつで、TDDが比較的にミクロにクラスやモジュールの動作への期待を書くことに注目するのに対して、ATDDはよりマクロな視点で、システムやサブシステム全体の受け入れ基準を記述することに注目しています。 かなり大雑把にいえば、TDDは単体テストに近いレイヤで、ATDDはE2Eテストに近いレイヤで

    受け入れテストを日本語で書ける Jest 拡張 "Jest-gauge" を公開しました
  • 酒類総合研究所で学んだこと – SakeTips!

  • 電通 Bチーム

    電通 Bチーム は Plan B Alternative Approach 新しいプロセス いままでと違うやり方 をつくっています。 電通Bチームは、A面(業)以外に、個人的なB面を持った社員たちが集まり、 いままでと違うやり方=planBを提案する「オルタナティブアプローチ」チームです。 閉塞感を打破する、21世紀的な新しいプロセスをご提供します。 What we do Bチームは、どうオルタナティブなのか? チームの組成 DJや小説家から、AI、金融まで。業の広告業以外に、個人的活動を行う、つまりB面を持つ社員約50名を、社内横断で組織化。 元々その事が好きでやってきたメンバーばかりの「好きこそものの上手なれ」スペシャルプランニングチームです。 情報の収集 アイデアやイノベーションは、異なる情報の掛け算や新結合と言われます。 Bチームのメンバーは、新しいものを生むのに寄与しそうな情

    電通 Bチーム
  • バーナーリングカバー | 商品情報 | 東洋アルミエコープロダクツ株式会社

    バーナーリングカバー 天板がフラットなガスコンロ用、バーナーリングの汚れを防ぐ商品。 コンロに馴染むヘアラインデザインのグレーとベージュ2柄展開。 ビルトインガスコンロ用 ガステーブル用 材質 アルミニウミムはく サイズ 約14x14x0.5cm 入数 5枚 おたのしみマーク ♥♥枚

    バーナーリングカバー | 商品情報 | 東洋アルミエコープロダクツ株式会社
  • アジリティを支える品質特性 / Agility and Quality Characteristics Developers Summit 2021 Summer

    Developers Summit 2021 Summer[A-1]アジリティを支える品質特性 講演日時: 2021年07月30日(金) 10:00 ~ 10:45 概要: ビジネスにとってITは、「あると便利」から「有効」、「不可欠」を経て「中核そのもの」になりつつあり、柔軟かつ俊敏に…

    アジリティを支える品質特性 / Agility and Quality Characteristics Developers Summit 2021 Summer
  • 私たちは数学でできているのか? 数学は実在か?

    ザビーネ・ホッセンフェルダーのブログより。 物理学にはたくさんの数学が使われていることは、皆さんもご存知でしょう。しかし、私たちが自然を説明するために使用する数学と、自然そのものの違いは何でしょうか? 何か違いがあるのでしょうか? それとも、それらは同じものであり、すべてが数学であると言えるのでしょうか? それが今日お話しすることです。 以前、複素数についてのビデオのコメントで、多くの人が「数字は実在しない」と言っていることに気づきました。しかし、もちろん数字は実在します。 その理由は次の通りです。あなたはおそらく、私を「物」だと思っているでしょう。なぜでしょう? なぜなら、私はグリーン・スクリーンの前に立ち、「human」の「h」が無音でないことを思い出そうとしている人間であるという仮説が、あなたの観測結果をどの仮説よりもよく説明しているからです。例えば、私がコンピュータで作られたもの

  • 無料で文章から自動で読み上げ音声を合成してくれるソフト「VOICEVOX」を使ってみた

    「誰でも100種類の声に変換できるAIボイスチェンジャー」や「ディープラーニングで誰でも簡単に結月ゆかりの声になれる技術」を開発したDwango Media Villageのエンジニアであるヒホさんが、入力した文章から自動で読み上げ音声を合成してくれるオープンソースのソフト「VOICEVOX」を公開したので、実際に使ってみました。 VOICEVOX https://voicevox.hiroshiba.jp/ ???????????????????????????????????????????????????????????????? 無料で使える中品質なテキスト音声合成ソフトウェア、#VOICEVOX をリリースしました ???????????????????????????????????????????????????????????????? ぜひダウンロードして遊んでみてくださ

    無料で文章から自動で読み上げ音声を合成してくれるソフト「VOICEVOX」を使ってみた
  • GMOあおぞらネット銀行

    GMOあおぞらネット銀行