並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 2750件

新着順 人気順

仕様書の検索結果1 - 40 件 / 2750件

  • NTT フレッツ光における通信速度などの現状について、背景や仕組みから正しく理解する 2020

    会社でフルリモート体制が築かれるにつれ、各スタッフの自宅の回線などについての相談を受けることが増えてきました。ということで、筆者 sorah の見解として 2020 年の NTT フレッツ光網について、主に通信速度や輻輳についての問題を理解するための背景と仕組みを説明しようと思います。 理解が間違っていたら教えてください。なるべく総務省や NTT の資料からソースを集めてきた上で説明していますが、出典不明の情報も混ざっているかもしれません。できるだけ具体的な出典を文単位で示していますが、複数の資料に渡る複雑なトピックに関しては文末に纏める形になっています。 技術的な意味での細かい解説よりも複雑な事情や背景の説明が中心です。フレッツ光とか NGN とか IPoE とか IPv6 とか v6 プラス・アルファみたいな言葉を聞いて、なんでそんな難しいんだと思った人も多いんじゃないでしょうか。エン

    • 2020年「はてなブックマーク年間ランキング」トップ100 - はてなニュース

      はてなブックマークのブックマーク数が多い順に記事を紹介する「はてなブックマーク年間ランキング」の2020年版を発表します。上位トップ100の記事をピックアップしました(集計期間:2019年12月11日~2020年12月10日)。 2020年 はてなブックマーク年間ランキング(2019年12月11日~2020年12月10日) 順位 タイトル 1位 普通の人が資産運用で99点をとる方法とその考え方 - hayato 2位 NTT フレッツ光における通信速度などの現状について、背景や仕組みから正しく理解する 2020 - diary.sorah 3位 資産運用 - shao's Scrapbox 4位 良い歯医者を見つける唯一の方法|おてう|note 5位 ’89 牧瀬里穂のJR東海クリスマスエクスプレスのCMが良すぎて書き殴ってしまった|pato|note 6位 この英単語を覚えるだけで、英文

        2020年「はてなブックマーク年間ランキング」トップ100 - はてなニュース
      • テクニカルライティングの基本

        テクニカルライティングの基本を学べます。サイボウズの新入社員向け研修資料です。業務マニュアル、報告書、仕様書、技術解説書などのドキュメントを書く機会がある方向け。 Twitter:https://twitter.com/naoh_nak 2023年度のアップデート版もあります:https://speakerdeck.com/naohiro_nakata/technicalwriting2023

          テクニカルライティングの基本
        • Google社のテクニカルライティングの基礎教育資料がとても良かったので紹介したい - Qiita

          はじめに エンジニアにとって、仕様書などの技術的な文章を書くこと(テクニカルライティングとも言います)は避けて通れません。ただ20年来多くのエンジニアの方々と同僚として接してきて思うことは、エンジニアの方の中には「文章を書く」ということに苦手意識がある方が一定数いるということです。 でもこの「テクニカルライティング」のスキルは、才能というよりは一種の「技能」だと思うんです。ある一定の原理原則を理解して実践を繰り返すことで、必ず一定レベルで習得できるものだと著者は信じています。 もしこのテクニカルライティングの原理原則をまだ体系的に学習したことがない、または過去学習したが改めて再学習したいという方に、お勧めのコンテンツを見つけたのでご紹介します。 https://developers.google.com/tech-writing Every engineer is also a write

            Google社のテクニカルライティングの基礎教育資料がとても良かったので紹介したい - Qiita
          • どうしてHTML5が廃止されたのか | フューチャー技術ブログ

            フロントエンド連載の5記事目です。 HTML5が2021年の1月に廃止されました。 Webエンジニアとしてバリバリ活躍されてる方やエグゼクティブテックリードのような肩書きを持つ方にとっては「何をいまさら」という話題かと思います。 しかしながら、今年も新人さん入ってきてくださったので、プログラミングを学習中にHTML5という文字列に悩まされないように、そもそもHTML5とは何かや、廃止された経緯をまとめてみます。 HTML5とはWebサイトを作るときに必ず書くことになるHTML。Webサイトのコンテンツ、つまり中身や構造を作るために使うマークアップ言語です。 そして、その最近版として10年ほど前に登場したHTML5。当時は Webニュースなどで盛んに特集が組まれていましたが、このHTML5がついこないだ、2021年1月28日に廃止されました。 広義のHTML5 / 狭義のHTML5HTML5

              どうしてHTML5が廃止されたのか | フューチャー技術ブログ
            • 何故お役所ってオワコンIEが大好きなの?|楠 正憲(デジタル庁統括官)

              普通は役所のシステムって構築してから5年とか7年は塩漬けにして使うもので、一度やらかしてしまうと名誉挽回の機会なんて向こう数年は与えられないんだけど、こと本件に関しては高市総務大臣から「今すぐ私がマニュアルなしでも使えるように直しなさい」と叱責いただいて、しっかりと予算的なサポートも得られたことで、たったの数ヶ月で立て直すことができた。 この数ヶ月は外部のセキュリティやPKIの専門家の方から様々なサポートをいただいて何とか実現したんだけれども、役所のシステム開発としては非常識というか、極めて難易度が高い案件だった。「え?単にChromeやSafariをサポートするだけでしょ、難しい訳ないじゃん」と思う諸兄は、もうしばらくこの話に付き合って欲しい。 もともとマイナポータルは日本を代表するITベンダーと通信キャリアの3社が開発したんだけど、大臣からの叱責を受け「ちゃんとお金を払うから直してよ」

                何故お役所ってオワコンIEが大好きなの?|楠 正憲(デジタル庁統括官)
              • 中途入社や部署異動で来た新メンバーを活躍しづらくするアンチパターン - Qiita

                1. はじめに ソフトウェア開発のチームに、新しいメンバーが入ってくることはよくあります。 以前に新卒社員がチーム入ってきた場合の育成方法を紹介しました(こちら)。 今回は、新卒社員ではなく、他の会社から中途入社か同じ会社の部署異動で来る新メンバーの話です。 (エンジニアが数百人などで規模が大きい会社の場合、部署が違うと仕事のやり方が全く変わる場合があるので、今回は中途入社と他の部署からの異動を同じように「新メンバー」として扱います) 会社や部署が変わると仕事のやり方が大きく変わるため、仕事のやり方に戸惑うことが多いと思います。 本稿では、そのような「新メンバー」を活躍しづらくしてしまうアンチパターンとその対策を紹介します。 2. 中途入社や部署異動で来た新メンバーが適応することの困難さを理解する 中途入社や部署異動で来た新メンバーが組織に適応することは、新卒社員のそれとは別の難しさがあり

                  中途入社や部署異動で来た新メンバーを活躍しづらくするアンチパターン - Qiita
                • いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。|Fritz | Lead Product Manager @ Mercari

                  いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が(たぶん) IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・ 良い仕様書がもたらす 5 つの効果 ・ 仕様書の重要性が増していく 2 つの理由 ・ 仕様書に含めたい 14 の項目・実戦編 ・ 仕様書作成時に心に留めたい 3 つのこと ・ 具体的な仕様書サンプル(

                    いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。|Fritz | Lead Product Manager @ Mercari
                  • [CEDEC 2021]フランス人開発者が,日本のゲーム業界の常識を斬る。「日本で世界規模の競争力のあるゲーム開発は可能なのか?」聴講レポート

                    [CEDEC 2021]フランス人開発者が,日本のゲーム業界の常識を斬る。「日本で世界規模の競争力のあるゲーム開発は可能なのか?」聴講レポート ライター:箭本進一 日本で活躍するフランス人開発者が,日本ゲーム業界の問題点を指摘するという講演「Is Worldwide Competitive Game Development possible in Japan?/日本で世界規模の競争力のあるゲーム開発は可能なのか?」が,ゲーム開発者向けカンファレンス,CEDEC 2021の2日目となる2021年8月25日に行われた。日本のゲーム業界が「マネジメント」「キャリア」「競争力」の3分野に抱える問題とは,どのようなものなのだろう? 「CEDEC 2021」公式サイト 講演を行うハンサリ・ギオーム氏は,東京に本拠を置くゲーム開発スタジオWizcorpのCEOを務めている。2006年に日本に住み始めて以

                      [CEDEC 2021]フランス人開発者が,日本のゲーム業界の常識を斬る。「日本で世界規模の競争力のあるゲーム開発は可能なのか?」聴講レポート
                    • テクニカルライティングの基本 2023年版

                      テクニカルライティングの基本を学べます。業務マニュアル、報告書、仕様書、技術解説書などのドキュメントを書く機会がある方向け。 サイボウズの2023年度 新入社員向け研修の資料です。 Twitter:https://twitter.com/naoh_nak 2022年版(初版):https://speakerdeck.com/naohiro_nakata/technicalwriting

                        テクニカルライティングの基本 2023年版
                      • デザインが苦手な人へ。デザインの四大原則を押さえれば格段にクオリティ上がるよ→素人が作るチラシや仕様書などにも有益

                        カトウヒカル@2/9書籍発売予約受付中! @design_hikaru [デザインが苦手なあなたへ] デザインの四大原則で、あなたの制作物はもっ〜と良くなる。 ➀近接 → 仲間ごとにグルーピング ➁整列 → 透明な線に揃える ➂強弱 → メリハリを付ける ➃反復 → 見やすい統一感 デザインで迷子になったら四大原則を思い出して、基本に立ち戻ろう!! pic.twitter.com/VMQbAVdeiT 2020-01-06 12:52:29

                          デザインが苦手な人へ。デザインの四大原則を押さえれば格段にクオリティ上がるよ→素人が作るチラシや仕様書などにも有益
                        • 【ChatGPT】個人的お気に入りプロンプトまとめ

                          あなたは、プロの【その分野の専門家】です。 以下の制約条件と入力文をもとに、【出力内容】を出力してください。 # 制約条件: 【前提条件や決まりごと】 # 入力文: 【期待する出力結果や大まかな指示】 あなたは、プロのエンジニアです。 以下の制約条件と入力文をもとに、ブログ記事の内容を出力してください。 # 制約条件: ・重要なキーワードを取り残さない。 ・文字数は30000文字程度 # 入力文: Swaggerについて技術ブログに投稿する文章を書いてください。 構成は、Swaggerとは?、Swaggerのユースケース、Swaggerのメリットとデメリット、Swaggerの書き方(YAMLファイル)、Swaggerの実行方法、まとめです。 構成間で重複した説明は省くようにしてください。 読者がブログを読みながらSwaggerを触れるようにハンズオン形式などを取り入れて文章を作ってください

                            【ChatGPT】個人的お気に入りプロンプトまとめ
                          • 【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG

                            Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1~2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文: www.industrialempathy.com 関連書籍: Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安:11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ

                              【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG
                            • ソフトウェアエンジニアなら3秒で理解できる NFT 入門 - Okapies' Archive

                              はじめに NFT って何ですか? ブロックチェーン上に記録された一意なトークン識別子をその保有者のアドレスと紐付ける情報、およびそれを状態変数として保持するスマートコントラクトのこと。 以上。 え、それだけ? はい。 「デジタル資産に唯一無二性を付与するインターネット以来の革命」なんじゃないの? これを読んでください: speakerdeck.com なるほど。ところで、この記事は何? いま話題の NFT について、NFT の標準仕様である EIP-721 の仕様書と、それを実装しているスマートコントラクトのソースコードから読み解けることを解説する。一般向けの解説とは異なる視点から光を当てることで、ソフトウェアエンジニアに「あ、NFT って単にそういうことだったのか」と理解してもらえるようにすることを狙っている。 また、NFT がソフトウェアとして具体的にどう実装されているかを知ることは、

                                ソフトウェアエンジニアなら3秒で理解できる NFT 入門 - Okapies' Archive
                              • 45歳多重派遣プログラマの退職エントリ

                                45歳多重派遣と言っても、噂のGitHubの人ではない。すまんな。。 皆さんはプロジェクトの共有ディレクトリの最下層に”女子大生”という何もないファイルを作ってアクセスログをとっていたのがバレて怒られた事はあるか?私はある。2回。 人は暇なとき、意外とディレクトリをめぐる旅をするものだ。 仕事でとうとうGitHubすら使わずにプログラマ人生を終えてしまった。 レガシーな技術を使いがちな金融プログラマではそこそこ居るのでは無いだろうか。 年収は20代後半からは550万~700万位だった。残業代・退職金は無く交通費は出ない。 所属会社は営業も事務も居ない小さな所帯のフリーの集まりのような所で、会社の運営に必要な金額をある程度毎月納めれば良い会社だった。 仕事がなくなれば自分、もしくは他社員の人脈で仕事をとってくる。フリーで居るよりは仕事を取りやすく、単価も上げやすいので一応会社の所属にしている

                                  45歳多重派遣プログラマの退職エントリ
                                • 仕様書の参考例と、こんな内容を仕様書に最低書くといいというお話|田辺めぐみ

                                  よく、仕様書を書いていなくて、書いてみたいけど、具体的な仕様書がネット上に落ちてなくってこまってるって相談を受けるので 「仕様書の記載内容のイメージ」を作りました! ※前提として「現在仕様書を書いていない、自社開発のMVP検証前後のフェーズのスタートアップ向け」に書いています。PMが仕様書、エンジニアがDesign Docを書く分担です。 ついでに、システム開発の基礎である「システム開発のV字モデルをベースにした設計書の紹介」も含めてまとめてみましたー! 大規模開発に使われたり、古くからあるフレームワークなので、スタートアップの方だと、システム開発のV字モデルの概念やそれにあわせた成果物を知らない人が多いけど、「要件定義書」と「設計書」を全てドキュメント化するとどうなるかを理解した上で、「仕様書」として情報を削る方が、考慮漏れ防止やエンジニアがやっている設計内容の理解につながるので、全体を

                                    仕様書の参考例と、こんな内容を仕様書に最低書くといいというお話|田辺めぐみ
                                  • プロダクトマネジメントと事業開発に関する私的な振り返り - 下町柚子黄昏記 by @yuzutas0

                                    TL;DR 企画力が…欲しい… pic.twitter.com/hJfr0qNv7T— ゆずたそ (@yuzutas0) 2020年11月19日 試行錯誤の瓦礫の記録です。 はじめに もくじ TL;DR はじめに もくじ 以前書いた記事 前提・免責 アイデア 1日1案(やってよかったこと) 1stスクリーニング(やってよかったこと) コミュニケーション チームへのリスペクト(やってよかったこと) 話す <<< 聞く(改善余地あり) 即決する(やってよかったこと) 自分で各論まで見る(やってよかったこと) 発散→収束でディスカッション(改善余地あり) イラストで話す(改善余地あり) 日次ミーティング(やってよかったこと) 議事録を書く(改善余地あり) 得た情報を共有する(改善余地あり) 想定納期を示す(改善余地あり) カレンダー招待&日程確約コメントを転記(改善余地あり) プロセス管理 仮説

                                      プロダクトマネジメントと事業開発に関する私的な振り返り - 下町柚子黄昏記 by @yuzutas0
                                    • プログラマーから見たPDFファイル - アンテナハウス PDF資料室

                                      更新日: 2020年8月14日 このページの目的 プログラマーは、クライアントから提供されたPDFファイルで、その要求を実現させようとしたとき、PDFのどんなところを見ているのでしょうか。このページでは、ちょっと珍しい視点でPDFファイルを解き明かしていきます。 自分でプログラムを書いてPDFファイルからテキストデータを取り出したいという人も、ぜひご一読ください。 はじめに PDFファイルをクリックすると、あたかも紙に印刷したかのように、どんなマシンでも同じような見た目で文章や画像がディスプレイに表示されます。 この単純な事実は、日常的にPDFファイルを利用していると当たり前に感じられるかもしれません。しかし、よくよく考えると驚くべきことです。 いったい、どのような仕組みがあれば、「過去から現在に至るさまざまな種類のコンピューターで見た目を変えずに同一の紙面を再現する」という目的を達成でき

                                        プログラマーから見たPDFファイル - アンテナハウス PDF資料室
                                      • 2019夏、先輩が若手に贈る「お世話になった技術書60選」- 入門からガチまで – | DevelopersIO

                                        「この本にはお世話になったなぁ〜」 「今でもたまに読み返してます」 「マジでめちゃめちゃ影響受けた」 「そう、こいつが俺のエンジニア人生を変えやがったんだ...」 ↑「こんな本を紹介してください!」と社内チャットで投げてみたら、すんごいことになったのでそのリストをシェアさせていただきます。 ※推薦理由はあくまで推薦者による個人的な意見や思い入れたっぷりなので、それを踏まえてお楽しみください。 目次 アプリケーション/プログラミング ドメイン駆動設計 Java言語で学ぶデザインパターン入門 Pro Git BINARY HACKS Effective Java リバースエンジニアリング―Pythonによるバイナリ解析技法 なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 リーダブルコード メタプログラミングRuby 第2版 Head First デザインパターン テスト駆動開発 C

                                          2019夏、先輩が若手に贈る「お世話になった技術書60選」- 入門からガチまで – | DevelopersIO
                                        • 「怠惰・短気・高慢」であれ、ChatGPTを使って業務効率化しよう(要件定義編)

                                          例として読書記録アプリをつくります! 筆者が欲しいサービスを作ろうと思い、今回は「読書記録アプリ」をつくります。 最低限の要件は、次のように設定しました。 デモアプリの要件(読み飛ばしてOK) 読書記録アプリを作る目的 読書が苦手なエンジニアが読書記録をし、記録を共有することで、継続して技術本を読めるようになること ターゲット 新人、中堅のWebエンジニア おおまかな要件 ユーザーは新規登録することで、読書記録アプリにログインできる ユーザーは読む本を登録できる ユーザーは本を何ページ読み終えたかを記録できる ユーザーは本を読み終わったら次の本を登録できる ユーザーは他の人がどの本を読んでいるのか、また何ページ読み終えたかを閲覧できる 質問する前に... また、ChatGPTに業務で使用するコードを渡す場合、環境キーやサービスを特定できる情報を送信しないでください。入力内容が他の人に渡って

                                            「怠惰・短気・高慢」であれ、ChatGPTを使って業務効率化しよう(要件定義編)
                                          • 技術文書の書き方

                                            howto-tech-docs.md 技術文書の書き方 このメモは、私(@ymmt2005)が長年にわたってソフトウェアプロダクト開発に関わってきて 2022年現在こうしたほうが良いと考えているベストプラクティスです。 科学的な分析等に基づくわけではない経験則であるため、今後も随時見直すことがありますし、 ここに書いてあることが常に正しいわけでもあらゆるソフトウェア開発に適するわけでもありません。 しかしながら、実務経験が豊富で、モダンな技術スタックに明るいエンジニアの経験則は一定の 役に立つのではないかと考えて記します。 技術文書とは ここでは、ソフトウェア開発で技術者が書くべき文書ということにします。 ソフトウェアエンジニアにも役割がいろいろあり、アーキテクトと independent contributor では書く文書が違うということはあるでしょうけれど、ここではごっちゃにします。

                                              技術文書の書き方
                                            • コンピュータサイエンスが気になるプログラマに勧める書籍リスト - Rubyist Magazine 第61号 巻頭言

                                              コンピュータサイエンスが気になるプログラマに勧める書籍リスト Rubyist Magazine 第 61 号をお届けします。 (今回は内容に合わせて文体を変えております。ご了承ください。) さて、コンピュータサイエンス(以下「CS」)は知らないけど日々プログラミングしている、というプログラマの方はたくさんいらっしゃるかと思います。 そんな方でも、ふとCSを知ってる方がいいのかなとか、CSも知らないとまずいのかな……などと思い、改めて勉強してみたいけどとっつきが悪いとか、うっかり手にとったCSの教科書が何を言ってるかさっぱりで10秒で閉じた、という方もいらっしゃるかと思います。 それでもCSが気になるので、「本腰を入れて勉強をする前に、どういうことをやってるのか眺めてみたい」くらいの温度感の方向けに、CSに隣接するジャンルで、職業プログラマや趣味プログラマの人なら読めそうな書籍のリストを作っ

                                              • エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita

                                                本記事は、Engineering Manager Advent Calenderの1日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。 このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていっ

                                                  エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita
                                                • 絶対に教科書に載らない桃鉄の(ついでにコナミとハドソンの)歴史|初心カイ

                                                  はじめに 桃太郎電鉄 ~昭和 平成 令和も定番!~ が累計販売本数350万本を突破しました。おめでとうございます。 最新ニュースを掲載しました。 『桃鉄』と「日清焼そばU.F.O.」の異色コラボが実現! ~ 『桃鉄』 の累計販売本数は350万本を突破 ~https://t.co/AGox7AEIDw pic.twitter.com/8yPM7ozeRv — KONAMI 企業広報・IR (@Konami_PR_IR) March 22, 2022 この売上は驚異的なものです。日本において300万本以上売り上げたゲームソフトは、実は「任天堂/ポケモン関連」「ドラゴンクエスト」「ファイナルファンタジー」「モンスターハンター」「妖怪ウォッチ」しかありません。とんでもない化け物IPたちに桃鉄が仲間入りした、ということになります(元から長年の歴史を組んだ化け物IPな気がしますが)。 さて、そんな桃鉄

                                                    絶対に教科書に載らない桃鉄の(ついでにコナミとハドソンの)歴史|初心カイ
                                                  • 図解 X.509 証明書 - Qiita

                                                    はじめに X.509 証明書について解説します。(English version is here → "Illustrated X.509 Certificate") ※ この記事は 2020 年 7 月 1 日にオンラインで開催された Authlete 社主催の『OAuth/OIDC 勉強会【クライアント認証編】』の一部を文書化したものです。勉強会の動画は公開しており、X.509 証明書については『#4 X.509 証明書(1)』と『#5 X.509 証明書(2)』で解説しているので、動画解説のほうがお好みであればそちらをご参照ください。 1. デジタル署名(前提知識) この記事を読んでいただくにあたり、デジタル署名に関する知識が必要となります。つまり、「秘密鍵を用いて生成された署名を公開鍵で検証することにより」、「対象データが改竄されていないこと」や「秘密鍵の保持者が確かに署名したこと

                                                      図解 X.509 証明書 - Qiita
                                                    • 接触確認アプリCOCOAからの教訓|情報処理学会・学会誌「情報処理」

                                                      楠 正憲(内閣官房 政府CIO 補佐官) 2021年1月 Android版の接触確認アプリCOCOAが数カ月にわたって動作していなかったことが明らかにされた.筆者は 2020年4月から接触確認アプリの導入について,有志での議論に参加し,有識者会議のメンバとして,また途中から政府CIO補佐官として, 接触確認アプリの導入を支援してきた.本稿では接触確認アプリCOCOAの開発と運用について,どのような課題があったかについて振り返る. 接触確認アプリ導入の経緯 筆者が接触確認アプリについて知ったのは昨年(2020年)3月頃のことである.ちょうどシンガポールのTrace Togetherが話題となって,日本でも接触確認アプリをリリースできないかといった話題で,いくつかのコミュニティが盛り上がり始めた. Androidのシェアが高いシンガポールに対して,日本ではiPhoneのシェアが非常に高く,iP

                                                        接触確認アプリCOCOAからの教訓|情報処理学会・学会誌「情報処理」
                                                      • 高校生がリアルタイム投票サイトを公開したらいきなり1万PVを記録した話 - Qiita

                                                        今回は高校生の私たちが公開した投票サイトが三日で1万PVを記録したので、その経緯をサイトの紹介も含め、全て公開します。 qiitaで後日談を書きましたので、よかったらお読みください リンクはこちらです サイトの内容 名前はAICEVOTE(アイスボート) リンクはこちら ----> aicevote.com(大量アクセスで現在サーバーが不安定な状況です。ご了承ください。) このサイトを一言で言うとこんな感じです。 "投票用紙を氷に見立てた次世代のリアルタイム投票サイト" AICEVOTEとは 普通の投票とAICEVOTE(アイスボート)の違い 普通の投票 普通の投票では、投票箱A/Bに最終的に投票された票の数の比で結果が決まります AICEVOTE AICEVOTEでは投票用紙の代わりに氷を投票します。 それぞれの投票箱の底は網目になっています 時間が経てばあなたが投票した氷は少しずつ溶け

                                                          高校生がリアルタイム投票サイトを公開したらいきなり1万PVを記録した話 - Qiita
                                                        • IPA のけしからん技術が再び壁を乗り越え、セキュアな LGWAN 地方自治体テレワークを迅速に実現

                                                          IPA のけしからん技術が再び壁を乗り越え、セキュアな LGWAN 地方自治体テレワークを迅速に実現 2020 年 11 月 3 日 (火) 独立行政法人情報処理推進機構 (IPA) 産業サイバーセキュリティセンター サイバー技術研究室 登 大遊 独立行政法人 情報処理推進機構 (IPA) 産業サイバーセキュリティセンター サイバー技術研究室は、このたび、できるだけ多くの日本全国の地方自治体 (市町村・県等) の方々が、LGWAN を通じて、迅速に画面転送型テレワークを利用できるようにすることを目的に、J-LIS (地方公共団体情報システム機構) と共同で、新たに「自治体テレワークシステム for LGWAN」を開発・構築いたしました。 本システムは、すでに 8 万ユーザー以上の実績と極めて高い安定性 を有する NTT 東日本 - IPA 「シン・テレワークシステム」をもとに、LGWAN

                                                            IPA のけしからん技術が再び壁を乗り越え、セキュアな LGWAN 地方自治体テレワークを迅速に実現
                                                          • クリーンアーキテクチャ完全に理解した

                                                            clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心

                                                              クリーンアーキテクチャ完全に理解した
                                                            • 暗号鍵管理ガイドライン | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構

                                                              実際の暗号システムがセキュアに動作し続けるためには、暗号アルゴリズム自体がセキュアであるだけでは不十分で、データが保護される期間中、その暗号アルゴリズムが使用する暗号鍵もセキュアに管理されている必要があります。そのため、暗号鍵やデータのライフサイクルを踏まえた運用、安全な暗号鍵の保管、暗号鍵危殆化時の対策などを行う上で参考となるガイドラインを取りまとめています。 「暗号鍵管理システム設計指針(基本編)」の内容 「暗号鍵管理システム設計指針(基本編)」は、あらゆる分野・あらゆる領域の全ての暗号鍵管理システムを対象に、暗号鍵管理を安全に行うための構築・運用・役割・責任等に関する対応方針として考慮すべき事項を網羅的に提供し、設計時に考慮すべきトピックス及び設計書等に明示的に記載する要求事項を取りまとめたガイドラインとして作成されたものです。 具体的には、暗号鍵管理の必要性を認識してもらうために「

                                                                暗号鍵管理ガイドライン | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構
                                                              • 社内勉強会で専門的技術力を高めるには

                                                                ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog サイトオペレーション本部に所属している大津と申します。普段CDNとNode.jsサポートの仕事をしていて、第9代黒帯(ヤフー内のスキル任命制度/ネットワーク・セキュリティ)に任命していただいています。1 先日ヤフー社内で黒帯LT会が開催されました。お題目は事前に指定された「専門的技術力を極めるための極意」ということで、10分ほど話をしました。しかし、これまでみたいにセミナールームで大勢の前で話すわけではなく、最近代わり映えしない自宅デスクからのオンラインLTは、正直勝手が違いました。時間配分もミスって中途半端に終了です。と思いきや数日前、このYahoo! JAPAN Tech Blog担当者から「いやー、よかったですよ。そのネタ書

                                                                  社内勉強会で専門的技術力を高めるには
                                                                • 三菱MRJはなぜ失敗したのか|ブースカちゃん

                                                                  とても長くなりました。10,000字を超えています。 途中で読み疲れちゃうようだったら、ブックマークなどを利用して、分けて読んでいただけると幸いです。 なにがあったのか、まず事実関係を確認「売れなかった」からではない。一部の論者は「MRJはユーザーのニーズに合っていないから失敗した」とかいう誤解をしているようですが、そうではありません。ニーズに合っていたか、よい飛行機だったか、という問題ではないのです。旅客機の開発はお金と時間がかかるので、最初に「見込み客」との契約を行い、それが成立した時点で開発を決定するのです。この顧客を「ローンチ・カストマー」と言います。 MRJの場合、ローンチ・カストマーは全日空でしたが、開発が進むにつれて海外からの発注も獲得しており、将来的に採算がとれるかどうかは別として、「顧客ニーズに合わない」的外れの製品ではありませんでした。 もちろん、これから開発する飛行機

                                                                    三菱MRJはなぜ失敗したのか|ブースカちゃん
                                                                  • 社内ドキュメントはなぜ更新されないのか?情報の鮮度を最小限の運用負荷で維持する「イミュータブルドキュメントモデル」のススメ - KAKEHASHI Tech Blog

                                                                    はじめに こんにちは。カケハシの各プロダクトを支えるプラットフォームシステムの開発チームでテックリードを担当しているkosui(@kosui_me)です。 プロダクト開発の世界では、明瞭な社内向けドキュメントを書くための方法が数多く提案されてきました。読者の中には、製品要求を明瞭にするためにPRD (Product Requirements Document、製品要求仕様書) を書き、プロジェクトの背景から全体の設計やその代案について明瞭にするためにDesign Docsを書き、アーキテクチャに関する意思決定の記録を明瞭にするためにADR(Architecture Decision Record) を書いてきた方も数多くいらっしゃると思います。 しかし、どんな素晴らしいドキュメントも、何故か更新されなくなります。新メンバーへのオンボーディングのためにインフラ構成図を検索したあなたが見つけた

                                                                      社内ドキュメントはなぜ更新されないのか?情報の鮮度を最小限の運用負荷で維持する「イミュータブルドキュメントモデル」のススメ - KAKEHASHI Tech Blog
                                                                    • 設計書・仕様書のレビュー方法を定めたJIS規格登場 チェック体制を標準化しやすく

                                                                      経済産業省は11月22日、システム開発時に使う設計書・仕様書などの「作業生産物」のレビュー工程についてJIS規格を制定したと発表した。仕様書などの見直し方や観点などを規格化し、ソフトウェアの品質向上や開発の効率化を促す。 「JIS X 20246」は、設計書・仕様書の見直し作業を「計画作業」「レビューの立ち上げ」「個々人のレビュー」「要検討項目の共有および分析」「修正作業および報告作業」の順に整理し、実行するべきタスクや手順を規定するもの。システム開発や試験、保守などの場面で作るあらゆる仕様書に適用可能。 レビューの曖昧さをなくすため、「目的」「役割」などのレビューの観点10種、「執筆者確認」「同僚との机上確認」などのレビュー手法9種を定めた。JIS制定により、組織や個人のノウハウに依存することなく一定水準のレビューができるようになり、ソフトウェアなどの制作物の品質向上につながるとしている

                                                                        設計書・仕様書のレビュー方法を定めたJIS規格登場 チェック体制を標準化しやすく
                                                                      • 独身だけど新築戸建てを買った話(コメント返信を追記2).md

                                                                        独身だけど新築戸建てを買った話(コメント返信を追記2).md 独身だけど新築戸建てを買った話 この記事は Mobility Technologies Advent Calendar 2020 の2日目の記事です。 はじめに みなさんこんにちは。tetsukayです。 株式会社Mobility Technologies でソフトウェアエンジニア(Android, Flutter)として働いています。 突然ですが、私は先日家を購入しました。この記事は家を購入するまで考えたことや流れを赤裸々に ただ殴り書き しているだけですが、だれかの参考になればと思います。 動機 弊社は今年4月にDeNAのオートモーティブ部門とJapanTaxiが統合して誕生しましたが、DeNAだった時から週2程度のリモートワークが認められていました。 そんな最中新型コロナウィルスが猛威を振るいだしたわけですが以前から制度と

                                                                          独身だけど新築戸建てを買った話(コメント返信を追記2).md
                                                                        • 【追記あり】任天堂を辞めてから5年以上が経った

                                                                          追記はしないつもりでいた。 でも、ある1人だけにコメントを返させてもらう。 https://anond.hatelabo.jp/20201001022747 衝撃を受けた。 ここまであなたの心を傷つけるとは思ってもみなかった。 でも、あなたにだから正直に言わせてもらうけど、辞めたことは後悔していない。 5年以上が経ったとは言いつつ、もっともっと、かなり昔の話なので当時の感情を思い出すのは難しいけど、それでも転職という答えが幸せになるための道だったんだよ。 日記は2つともすべて読ませてもらった。 ありがとう。顔も知らないあなたの幸せを願っています。 新卒で入社した。もうかなり昔のことだ。 文系の学部出身で、事務職で応募して、もの凄く面倒くさいエントリーシートを書いて、何度かの面接の後に採用された。 企画部門への配属だった。生産管理を希望していたけど通らなかった。 増田でこんなことを書いている

                                                                            【追記あり】任天堂を辞めてから5年以上が経った
                                                                          • ChatGPTのおさらいと、プログラミングに活用するための第一歩 | gihyo.jp

                                                                            大量の文章から学習することで、多言語を取り扱う能力だけでなく、高度な推論能力まで手に入れました。 GPT-3.5、とりわけその初期モデルのCodexはGitHubに存在する5400万の公開リポジトリから採取された159GBのPythonコードでGPT-3をfine-tuning(微調整)することで生まれました。ChatGPTがとりわけPythonが得意なのはここから来ています。 ChatGPTの学習データを考えることはその能力を発揮させるときに極めて有効です。質問時も以下のように、『⁠涼宮ハルヒの憂鬱』というライトノベル作品について日本語で聞いたときはSOS団の略称を間違えるなどしますが、英語ではほぼ期待通りの回答を見せます。 図1 『ハルヒの憂鬱』について日本語で聞いた場合の回答 図2 『ハルヒの憂鬱』について英語で聞いた場合の回答 知ったかぶりをするChatGPT ところで、ChatG

                                                                              ChatGPTのおさらいと、プログラミングに活用するための第一歩 | gihyo.jp
                                                                            • ZOOMもUberもNetflixも、たった3万円で全てのシステム/アプリを作れるノーコードの衝撃

                                                                              ZOOMもUberもNetflixも、たった3万円で全てのシステム/アプリを作れるノーコードの衝撃 2021.06.09 Updated by Ryo Shimizu on June 9, 2021, 14:40 pm JST プログラマーというのは長じるとプログラムを書かなくなるものである。 特に最近はWebサイトくらいの簡単なものでも、決まり事が多くて書くのが億劫になってしまった。 大学生が適当に書いたHTMLをネットにバラ撒き散らしていた時代と異なり、今はSSL対応が必須になり、そのための証明書の管理もしなければならないし、スマートフォンでもPCでもタブレットでも綺麗にコンテンツが見えなければならない。 そうなると、もはやそれが専業の人以外は、お手上げだ。というか、できるだけ触りたくない、というのが本音である。 ところで筆者が創設に関わった「全国小中学生プログラミング大会」も今年で第

                                                                                ZOOMもUberもNetflixも、たった3万円で全てのシステム/アプリを作れるノーコードの衝撃
                                                                              • AI時代へ向けて育成すべきはAI人材か?|楠 正憲(デジタル庁統括官)

                                                                                今年3月に政府のAI戦略が年間25万人を目標にAI人材を育てるとぶち上げたのに続いて、教育再生会議が全ての大学生がAIなどの基礎的な素養を身につけられるように標準カリキュラムを作成することを提言した。ガートナーが2017年1月に産業界で2020年末時点で30万人以上のIT人材(原典を確認したところAI人材ではなかったようですね)が不足するといったらしいのだが、今からカリキュラムをいじったところで2030年くらいにならないとAIネイティブな新入社員は入ってこないし、その頃まで深層学習が流行っているのか、NVidiaが残ってるのか、PythonやTensorFlowが広く使われているのか、GAFAがどうなっているかなんてさっぱり見当がつかない。 残念ながら私たちは2010年代に深層学習の実用化の局面で米国に負けたのであって、いまから教育をいじるといったって泥棒を捕らえて縄を綯うような話である。

                                                                                  AI時代へ向けて育成すべきはAI人材か?|楠 正憲(デジタル庁統括官)
                                                                                • 市場は「なんかいい感じにしてくれる」エンジニアを求めているのではないか - 毎日がもふもふ

                                                                                  エンジニア不足、エンジニア不足と言われて久しいですが、日本でのプログラミングスクールの先駆けとも言えるTECH::CAMPさんのサービス開始が2014年なので、今や8年が過ぎようとしているわけです。 ともすると、市場に既にベテラン級のエンジニアがわんさかいてもおかしくないんですが、今でも「エンジニア採用できない」という声が絶えることないように見えます。はて?どうしたことだろうか、と思ったので今市場でどんなエンジニアが求められているのかを考えてみました。 高い技術力よりも「いい感じ」力を求めている エンジニアというと、技術を駆使して問題解決をするスペシャリストというイメージがあり、技術力が高い=優秀という認識を持つのが自然です。実際、技術力が低くてまともにプロダクト開発出来ないようでは論外だし、技術的な難問の攻略が命運を分けるケースはあるにはあります。 しかし、実際には開発プロジェクトの失敗

                                                                                    市場は「なんかいい感じにしてくれる」エンジニアを求めているのではないか - 毎日がもふもふ