並び順

ブックマーク数

期間指定

  • から
  • まで

81 - 120 件 / 458件

新着順 人気順

Pの検索結果81 - 120 件 / 458件

  • 「視覴」の謎

    ChatGPTが「視覴」という新語を発明したらしいことをフガクラさんのツイート(2023-06-08 08:51:02 JST)で知る。 すでに「視覴」は、いくつかの最近書かれたWebページで使われていた。ChatGPTで生成されたページらしい。ざっと検索して見つけたページを列挙しておく。いずれも最近作られたか修正されたページである(1件だけ2020年のページがあるが、最近修正されたものかどうか不明)。 映像・音声編集におけるノーマライズの重要性!(2023-05-11)「視覴的・聴覚的な一貫性」「視覴的な効果を最大化」「視覴的な混乱を避け」(2回)なお、このページは現在消えて視覴とは?AI(ChatGPT)が出力した新しい言葉なのか?(2023-06-08)にリダイレクトされ、「弊社では、2023年3月より用語集作成に際しAIライティングの試験運用を行っておりますが、この度、「視覚」の誤

    • ドメイン駆動設計に関する何か - 日々常々

      2020-03-13追記: 「ドメイン駆動設計」のハードルを上げる意図はありません。そもそもそんな特殊技能でもないと思っています。「ドメイン駆動設計が合っているか」を測る材料になるかも?くらいの気持ちで読んでいただけると幸いです。 何度目か知りませんがDDDがまたブームを迎えているようで。DDD難民と言う言葉が出た頃を思うと感慨深いですね。実際難民になったわけではないので肌感覚で知らないのが残念なところですが、これはどうでもいい。 DDD、日本語ではドメイン駆動設計となりますが、DDDを冠していてもドメインが語られることは少ないようです。 数ある書籍もドメインモデリングの話ではなく、ドメインモデルをいかに実装に落とし込むかにフォーカスしていると感じています。 これはこれで仕方ないと言うか、ドメインの話って広く語れないんですよね。 ドメインは領域で境界があって範囲が限定されています。特定ドメ

        ドメイン駆動設計に関する何か - 日々常々
      • Othello is Solved 論文解説 (私見) - Qiita

        今朝起きたら、とんでもない論文を見つけました。 Othello is Solved ゲームの オセロが"解かれた(弱解決)" というのです。飛び起きました。それで、16時まで二度寝してから読みました。 注意すべきは、この論文が査読を経て公開されているわけではないこと、つまり形式上特にチェックを受けたものではないことです。ただ、タイトルからして非常に衝撃的ですので、個人的に読んでみました。この記事では、私がこの論文(およびソースコード)を読んでわかったことを、なるべくわかりやすくまとめます。随時更新します。 余談ですが、このタイトルはどうやら、チェッカーというゲームが以前弱解決された際の論文"Checkers Is Solved"のオマージュだろうという話です。 この記事には専門用語が出てくるので、最後の方に基礎知識として重要な用語や知識をまとめました。 お詫びと訂正 この記事の内容は、私が

          Othello is Solved 論文解説 (私見) - Qiita
        • Rustでゲームボーイアドバンスエミュレーターを書いた

          一通りちゃんと実装したので、大抵はちゃんと動いてくれるはずです。動かなかったり、画面がおかしかったり、音がおかしかったりしたらバグなので、ご報告いただけるとうれしいです。 エミュレーションコアが2つになったので、せっかくなのでエミュレーションコアのインターフェースを抽象化して、マルチエミュレーターにしました。 リリースページ からコンパイル済みバイナリをダウンロードできます。 マルチエミュレーター エミュレーターを作るうえで割と面倒でバカにならないのがフロントエンドUIの作成です。GUIアプリを作るのはそもそも結構大変で、ましてや昨今のアプリケーションはPCだけでなくスマホやWebといったタイプの異なる複数のプラットフォームで動かしたいというモチベーションがあります。特定プラットフォームにべったりで何となく動くように書けばいいやというのと比べると、取れる選択肢も限られてかなり面倒になってき

            Rustでゲームボーイアドバンスエミュレーターを書いた
          • OSS 観光名所を貼るスレ - ぽ靴な缶

            これは はてなエンジニアアドベントカレンダー2023 2日目の記事です。 はてなエンジニア Advent Calendar 2023 - Hatena Developer Blog はてなエンジニアのカレンダー | Advent Calendar 2023 - Qiita トップバッターは緊張するけど、順番が回ってくるまで長い間ソワソワするのも嫌、という理由で例年2日目を狙うようにしている id:pokutuna です。今年も成功しました。 観光名所とは 目を閉じれば思い出す、あのコード... あの Issue... あなたが Web 系のエンジニアであれ、趣味で開発している方であれ、必要に応じてライブラリやフレームワークのコードを読むのはよくあることでしょう。公開の場で開発されているソフトウェアは、ソースコードだけでなく、開発コミュニティでの議論やバグ報告なども見ることができます。 リポ

              OSS 観光名所を貼るスレ - ぽ靴な缶
            • LINE、NAVERと共同で、世界初、日本語に特化した超巨大言語モデルを開発 新規開発不要で、対話や翻訳などさまざまな日本語AIの生成を可能に | ニュース | LINE株式会社

              LINE、NAVERと共同で、世界初、日本語に特化した超巨大言語モデルを開発 新規開発不要で、対話や翻訳などさまざまな日本語AIの生成を可能に 従来の特化型言語モデルとは異なる、汎用型言語モデルを実現予定。 処理インフラには世界でも有数の、700ペタフロップス以上の高性能スーパーコンピュータを活用 LINE株式会社(所在地:東京都新宿区、代表取締役社長:出澤剛)はNAVERと共同で、世界でも初めての、日本語に特化した超巨大言語モデル開発と、その処理に必要なインフラ構築についての取り組みを発表いたします。 超巨大言語モデル(膨大なデータから生成された汎用言語モデル)は、AIによる、より自然な言語処理・言語表現を可能にするものです。日本語に特化した超巨大言語モデル開発は、世界でも初めての試みとなります。 従来の言語モデルは、各ユースケース(Q&A、対話、等)に対して、自然言語処理エンジニアが個

                LINE、NAVERと共同で、世界初、日本語に特化した超巨大言語モデルを開発 新規開発不要で、対話や翻訳などさまざまな日本語AIの生成を可能に | ニュース | LINE株式会社
              • サーバダウンしたニコニコ漫画に何が起きていたのか - BOOK☆WALKER inside

                こんにちは。メディアサービス開発部Webアプリケーション開発課の奥川です。ニコニコ漫画のバックエンド開発を担当しています。 2021年初頭、ニコニコ漫画である作品の連載が開始されました。それに端を発する数カ月間のサーバ障害により、ユーザーの皆様には大変ご迷惑をおかけしました。 少し前の話にはなりますが、当時ニコニコ漫画のサーバでは何が起こっていたのか、どのような対応を行ったのかを振り返ってみたいと思います。 1号棟(事の起こり) 2021/01/08 問題の作品(以後、「作品I」*1と記述します)の第1話が投稿されます。その過激な内容からSNSなどでは一部で話題になりましたが、まだニコニコ漫画へのアクセスも穏やかなものでした。 2021/01/22 その2週間後、「第2話(前編)」の公開から事件が起こります。 ピークタイム最中の12:22頃から、まずmemcachedがCPU Utiliz

                  サーバダウンしたニコニコ漫画に何が起きていたのか - BOOK☆WALKER inside
                • WASMとRustはVue.js/React.jsを打倒するのか? - JSへの侵略の歴史

                  はじめに 「Typescriptの次はRustかもしれない」という記事がバズってるのを見かけました。 なかなか面白くて、PAとしてのWASMとRustを比較している記事です。ちょうど最近「レガシーおじさん、SPAを始めてみた。そして限界を知る」でも書いた通り最近SPAに手を出してみたのですが、いろいろやろうとするとSSRのためのBackend for Frontend (BFF)等が必要になるとわかり「これJSでやる必要なくない?」とも感じていたのでちょうど良かったです。 こういうのを見るとRIAやGWTのように似たアプローチで廃れた技術や、登場が早すぎたMeteor、今も頑張ってるMSのBlazorなど色々頭をよぎります。といわけで歴史を俯瞰する意味でHTML + JavaScriptとそれ以外の技術のせめぎ合いの歴史やMSのBlazorやRustのyewなどWebassemblyを使う

                    WASMとRustはVue.js/React.jsを打倒するのか? - JSへの侵略の歴史
                  • HTTPが全てを飲み込む(前編)~HTTPの2層構造と、HTTP Semanticsとは何か?

                    Webを構成する重要な要素の1つであるHTTPは、その最新仕様で2層構造となり、バージョンに関係なく使えるSemanticsと、特徴の異なる通信仕様を定めたHTTP/1.1、2、3に分割されました。 さらに現在では、HTTPの上にあらためてUDPやIP、イーサネットなどのプロトコルを実装する提案が行われており、まさにHTTPは通信の全てを飲み込む勢いで進化しつつあります。 こうしたHTTPの最新動向の解説が、大手CDNベンダでエッジクラウドなども展開するFastlyが2023年11月8日開催したイベント「Yamagoya 2023」で同社シニアプリンシパルエンジニアの奥一穂氏が行ったセッション「HTTPが全てを飲み込む」にて行われました。 本記事ではこのセッションをダイジェストで紹介していきます。記事は以下の3つに分かれています。 HTTPが全てを飲み込む(前編)~HTTPの2層構造と、H

                      HTTPが全てを飲み込む(前編)~HTTPの2層構造と、HTTP Semanticsとは何か?
                    • この10年のプログラミング言語の変化 - 西尾泰和のScrapbox

                      @nishio: あ、そうか、10年前からあったけど10年間の間に勢力を拡大したケースがあるからあんまり厳しく切らない方がいいのか(TypeScriptの登場が2012年、Rustの登場が2010年だった)

                        この10年のプログラミング言語の変化 - 西尾泰和のScrapbox
                      • 音楽プログラミング言語って結局なんなのさ? 1.言語仕様

                        音楽プログラミング言語って結局なんなのさ? 1.言語仕様published: 2021-02-12 last modified: 2023-07-25 この記事は続き物でおおよそ週間ペースを目指しています。 言語仕様(本記事)データとプログラムの境目言語とライブラリの境目松浦知也です。ここ2年ぐらい音楽のための新しいプログラミング言語mimiumを開発しています。 https://mimium.org/ja 最近この自分で作った言語を人に説明する機会がちょこちょこ増えてきたのですが、その度に「既存の音楽プログラミング言語と比べてどこが新しいのか?」という話にたどり着く前に「そもそも音楽をプログラミングで作るってどういうこと?」みたいな疑問に対する解説をしているうちに話が続かなくなってしまうようなケースが増えてきまして、なんかそういう超初歩的な解説があればいいのになあと思っています。 プログ

                          音楽プログラミング言語って結局なんなのさ? 1.言語仕様
                        • 複雑なシステムでは、すべての要素が正しくても障害が起きる。カオスエンジニアリングから継続的検証へ(前編)。JaSST'23 Tokyo基調講演

                          複雑なシステムでは、すべての要素が正しくても障害が起きる。カオスエンジニアリングから継続的検証へ(前編)。JaSST'23 Tokyo基調講演 Netflixが始めた「カオスエンジニアリング」は、現在では大規模なシステムにおける可用性向上の手法のひとつとして確立し、広く知られるようになりました。 そのカオスエンジニアリングという手法を定義したのが、元Netflixカオスエンジニアリングチームのエンジニアリングマネージャーを務めていたCasey Rosenthal(ケイシー ローゼンタール)氏です。 そのローゼンタール氏が、ソフトウェアのテストに関わる国内最大のイベント「ソフトウェアテストシンポジウム 2023 東京」(JaSST'23 Tokyo)の基調講演に登壇し、「Chaos Engineering to Continuous Verification」(カオスエンジニアリングから継続

                            複雑なシステムでは、すべての要素が正しくても障害が起きる。カオスエンジニアリングから継続的検証へ(前編)。JaSST'23 Tokyo基調講演
                          • 「Rustでやると知らないうちに詰む設計」を避けるためのTipsを集めてみる

                            とりあえず、よく言われてるやつから埋めていこうと思う。 構造体にライフタイムを持たせない 構造体にライフタイムを持たせるのは「基本的に」避けよ、というのが重要なのは間違いないのだけど、これをもう少し実践的な内容にしたい。ちょっと考えてみたけど、こういうのはどうだろうか。 ある関数呼び出しの中でしか絶対に使わない。returnするまでにその構造体のデータは全て破棄される。static変数に退避させることもできない。アロケーションもその関数が面倒を見る。そういう一蓮托生できる関数呼び出しに心当たりはあるか? ある→ 構造体にライフタイムを持たせてもよい。 ない→ ライフタイム禁止。 そう考えてみると、DIとかReduxとかとも通じるところがあるかもしれない。「つべこべ言ってないで全部の責務を一番外側に持っていく」という決断ができるときは構造体ライフタイムが選択肢に入る。

                              「Rustでやると知らないうちに詰む設計」を避けるためのTipsを集めてみる
                            • リリースノート管理術

                              みなさま、OSSの変更履歴、要するにCHANGELOGやリリースノートはどのように管理しておられるでしょうか。自分はというと、抱えるリポジトリも数百個に増えてきて、まあ要するに細かく管理するのがだるく、最近は変更履歴の管理方法も変わってきました。 CHANGELOGからGitHub Releasesへ 昔は、おおよそKeep a changelogの方式に準拠したCHANGELOG.mdを書いていました。semantic versioningでバージョン管理をしながら、個々のバージョンごとに次のセクションを設けて変更内容を説明するような感じです。 Added Changed Deprecated Fixed Removed Security 今は、新規につくるリポジトリではCHANGELOG.mdは用意せず、GitHub ReleasesにKeep a changelogに似た形式で変更内

                              • 川崎市様における証明書誤交付ついて(お詫び)

                                川崎市様における証明書誤交付ついて(お詫び)2023年5月2日に川崎市様において、証明書交付サービスと戸籍システムを連携させるために当社が開発した個別連携システムの通信連携プログラム(以下、当該プログラム)不具合により、証明書交付サービスで申請された方とは異なる住民の方の戸籍全部事項証明書が発行されるという事象が発生いたしました。 川崎市様ならびに証明書交付サービスをご利用の皆様に多大なるご迷惑ご心配をおかけいたしましたことを深くお詫び申し上げます。 本事象の原因は、2か所のコンビニで、2名の住民の方が同一タイミング(時間間隔1秒以内)で証明書の交付申請を行った際に、後続の処理が先行する処理を上書きしてしまうことによるものです。本事象の原因となった当該プログラムの不具合は、既に修正および入れ替えを完了しております。なお、当該プログラムは川崎市様以外では使用されておりません。 当社はこれまで

                                  川崎市様における証明書誤交付ついて(お詫び)
                                • GitHub に漏れ出た内部コードを探す ~ 上場企業 3900社編 ~ - ぶるーたるごぶりん

                                  全1回、このシリーズは今回で最後です! TL;DR 上場企業 3900 社程に対して、すごく大雑把な「内部コード等の漏洩調査」を GitHub 上で行った 結果としては、重要度の高いものから低いものまで 10社ほどで漏洩が確認された 重要度の高いものとして、社外秘っぽそうなスプレッドシート、社員のハッシュ化パスワード(BCrypt)、 AWS Credential 等 「大雑把な」調査を行ったが、より精度の高い方法等について記事内にて触れていく 脅威インテルとか DLP みたいなエリアとかも、外部企業とかに頼るだけじゃなく「自分たちでも」頑張ってみるのがいいんだと思います GitHub Code Search ... すげえぜ! Google Dorks ならぬ、 GitHub Dorks + GitHub Code Search でまだまだいろいろできるはず。 はじめに チャオ! 今回は

                                    GitHub に漏れ出た内部コードを探す ~ 上場企業 3900社編 ~ - ぶるーたるごぶりん
                                  • Chainer を振り返って

                                    2015 年 4 月 12 日に Chainer の最初のコードをコミットしてから,およそ 4 年半と少しが経ちました.はじめのはじめは軽い気持ちで書きはじめたコードでしたが,今では一線級の研究を立派に支えるまでになりました.深層学習フレームワークの世界も当時とは様変わりして(当時は TensorFlow も PyTorch もなかったわけですから,本当に変わりました),思えば遠くにきたものです. 今日,PFN は社内の研究開発に用いる主なフレームワークを PyTorch に移行すると発表しました.会社にとってももちろんですが,業務としてはこの 4 年半,Chainer 一筋でやってきた自分にとっては特に,大きな転換点です. まず率直な感想として,Chainer の開発は本当に楽しかったです.書きはじめた頃は,深層学習フレームワーク競争の真っ只中で,Theano の上に乗っかるフレームワー

                                    • OSSをベースにしたサービス提供の難しさ - knqyf263's blog

                                      背景 難しさ 利益相反になりがち 競合OSSの存在 コミュニティからのPull Request 競合サービスによる利用 レベニューシェアにならない 利用統計が取れない やっておくべきこと お金を払いたい機能を見極める 境界線を決める ライセンスについて考える 利用統計の取得方法について考える OSSから有償版へのスムーズな移行を考える まとめ 背景 弊社(Aqua Security)ではOSS開発をしており、そのOSSを組み込んだ有償サービスを売ることで利益を上げています。 自分はその中のOSS開発をフルタイムで担当しています。 会社は何を目的としてOSS開発をしているのか、というのは以前発表しました。 speakerdeck.com フルタイムOSS開発者をやってみての感想なども昔書いています。 knqyf263.hatenablog.com 今回はOSSをベースにしたサービス提供の難し

                                        OSSをベースにしたサービス提供の難しさ - knqyf263's blog
                                      • オンラインゲーム 10年の進化と同期方式の選び方 - きゅぶろぐ

                                        オンラインゲームを作ろう!と思ったことがある方は、 こちらの講演記事を1度は見たことがあるのではないでしょうか。 www.4gamer.net こちらの講演は、具体例を交えながら非常に分かりやすくオンラインゲームの主な同期方式が説明してあり、 2024年現在でもオンラインゲームの基礎を学ぶ資料として真っ先に名前を上げる最高の資料です。 しかしながら講演は2010年のものであり、オンラインゲームはこの10年余りで進化しています。 この辺りの進化の話を簡単にまとめつつ、オンラインゲームの同期方式の選び方を紹介します。 (上記講演記事の知識/用語を前提としているため、先に上記記事をお読みください。) オンラインゲームの民主化について 技術の話をする前に。 近年、「マルチプレイヤーゲーム」と聞いてオフラインの画面分割ゲームを想像する人はいないと言って良いほど オンラインゲームは民主化されてきました

                                          オンラインゲーム 10年の進化と同期方式の選び方 - きゅぶろぐ
                                        • 人月の神話

                                          人月の神話 をひさしぶりに読んでみた。 人月の神話は、フレデリック・ブルックスの超有名古典的エッセイ集で、ソフトウェアエンジニアリングに関する多岐にわたるトピック取り扱っている。その中でもとくに有名で、よく世間で言及されるのは、表題にもなってる「人月の神話」と「銀の弾などない」、それから「セカンドシステム症候群」あたりだろうか。 はじめて読んだのは20年くらい前。社会人になったばかりのころ、満員電車にゆられながら、「へー人を増やしても開発ってうまくいかないのねー」などとわかったような顔をしながら読んでいたのを覚えている。当時は職業プログラマとしての経験を積む前で、本を読んでも鵜呑みにすることしかできなかった。でも、熟練のプログラマとして経験を積んだいま読んだら、またなにか違った洞察を得られたりするかもしれない。読み返してみた動機はそんな感じ。 目次 現代のプログラマにとって有益か やっぱり

                                            人月の神話
                                          • メインフレームの異常処理 - Qiita

                                            はじめに この記事では、メインフレームでは異常時の処理でどのようなことをやっているのか、また、Linuxの異常処理との違いなどについて話してみようと思います。 この記事を書くに至った直接的なきっかけは、とある人からリクエストがあったからです。が、日ごろからメインフレームの異常処理の考え方については、PCサーバーやクラウドによるシステムがメジャーになった現代であっても、参考になることは多いと感じていてはいました。 筆者は今でこそLinux Kernel周りの仕事をしていますが、20年ぐらい前のころはメインフレームのOS開発部隊に配属されていて、メインフレームのとあるコプロセッサのドライバを書いたりしていました。この際、その異常処理における考え方を体験する機会が多々あり、当時のその経験が20年後の現在でも大いに役にたっていると感じていたからです。 そもそもメインフレームは、これまで長年にわたっ

                                              メインフレームの異常処理 - Qiita
                                            • 6年ぶりぐらいにクラウド使った結果、Kubernetes以外のマネージドサービスとか基本要らなくない?となった話 - データエンジニアの酩酊日記

                                              ここ半年ぐらい、かなり久々にクラウド使ってアプリやバッチの基盤作ったりしてきて、色々と思ったことを書き捨てる。 「ちょっと検証してみた」程度のものも含めれば、AWSとGCPは一通り主要なマネージドサービスを触ったし、実際に複数のアプリやらバッチやらをマネージドサービス上で本番稼働させて今も運用してるけど、結局DB以外は基本全部Kubernetesに乗せるのが一番楽だと強く思うようになった。 Kubernetesは学習コストや運用コストがそれなりに高く付くから安易に採用するのはどうなのか、みたいな論調もあるし、つい半年前までは自分もそう思ってた。サーバレスなマネージドサービスが色々出てきているのに、なんでわざわざKubernetesクラスタなんていう設計、運用に手間のかかるクラスタリングサーバーを立てて管理しないとならんのかと。 だけど、実際にいくつかのマネージドサービス使ってアプリやバッチ

                                                6年ぶりぐらいにクラウド使った結果、Kubernetes以外のマネージドサービスとか基本要らなくない?となった話 - データエンジニアの酩酊日記
                                              • 最近見かける新しいライセンスについて - Kengo's blog

                                                Elastic社のブログをきっかけに、最近見かける新しいライセンスについて個人的に調べてみた。私は専門家ではないので要注意。公開情報も隅々まで追えているわけではないし。 なお一部ライセンスはOpen Source Initiative (OSI)による承認を受けていないので、ここではオープンソースライセンスではなく単に「ライセンス」と書くことにする。 新しいライセンスが誕生している背景 従来のオープンソースライセンスが再頒布以外の利用をあまり想定していなかった。 Open-core modelないし完全オープンソース戦略を採る企業が自衛策を必要とした。 既存のライセンスが難解なため、理解しやすいライセンスが求められた。 OSS活動を収入に繋げるためのモデルが試行錯誤されている。 新しいライセンスを導入しているプロジェクト(一例) プロジェクト ライセンス Elastic SSPLと独自ライ

                                                  最近見かける新しいライセンスについて - Kengo's blog
                                                • Yahoo! トラベルと一休.com のシステム統合プロジェクト - 一休.com Developers Blog

                                                  今から二ヶ月ほど前、10/1 に Yahoo! トラベル のリニューアルが完了しました。このリニューアルは、一休.com と Yahoo! トラベルの2システムを一つに統合することで実現しました。 ご存知の通り、ヤフーと一休は同じグループに所属する企業です。ざっくりいうと「同じグループで2つの宿泊予約システムを開発し続けるのは効率が悪いよね」という話があり、今回のシステム統合に至っています。 Yahoo! トラベルと一休のシステム統合は、(1) 2017年頃にホテルの空室管理や予約、決済、精算業務などを担うバックエンドのシステム統合を行い、そして (2) 今回 2021年春先から半年ほどをかけて、ユーザーが利用する画面も含めた全面統合を行いました。全面統合は総勢で 50名ほどのディレクター、エンジニア、デザイナーが関わる一休的には大きな規模のプロジェクトになりましたが、目立ったトラブルもな

                                                    Yahoo! トラベルと一休.com のシステム統合プロジェクト - 一休.com Developers Blog
                                                  • どのようにしてプログラマはAIに仕事を奪われていくかの妄想

                                                    先日 OpenAI からChatGPTが Beta 公開された ChatGPT ではどんな質問に対しても何かしらの回答を生成してくれるのだが、ソースコードに関しても中々の筋が良さそうな雰囲気のコード片を生成してくれるということで少し話題になっていた こうしたプログラムを生成してくれる AI が発展していく中でどういう具合にプログラマの仕事が奪われていくのか興味がある 特に以下ではweb アプリやモバイルアプリなどのアプリケーションの開発においてという文脈で考えることにする まず AI がプログラマの仕事を奪うまでにはいくつかの段階があると思う コード支援レベル 現状はGitHub Copilotのようなコーディング支援を行うレベルの AI はある程度実用レベルになっている 自分は Copilot が生成したコード片をプロダクションコードに含めるのは権利関係の問題もあり様子見している しかし

                                                      どのようにしてプログラマはAIに仕事を奪われていくかの妄想
                                                    • Mojoは「C言語のように速いPython」なのか - k0kubun's blog

                                                      LLVMやSwiftを作ったChris LattnerがCEOをやっている会社が、Pythonの使用感とC言語並の性能を併せ持つ言語としてMojoをアナウンスした。 まだ手元で試せる状態でリリースされてはいないが、最大35000倍Pythonより速いという。 Mojo🔥 combines the usability of Python with the performance of C, unlocking unparalleled programmability of AI hardware and extensibility of AI models. Also, it's up to 35000x faster than Python 🤯 and … deploys 🏎 pic.twitter.com/tjT09U4F80— Modular (@Modular_AI) May

                                                        Mojoは「C言語のように速いPython」なのか - k0kubun's blog
                                                      • 暗号の歴史と現代暗号の基礎理論(RSA, 楕円曲線)-後半- - ABEJA Tech Blog

                                                        はじめに このブログに書かれていること 自己紹介 注意 Part3 現代の暗号 共通鍵暗号方式と鍵配送問題 鍵配送問題とは? 共通鍵暗号方式と公開鍵暗号方式の違いとメリット・デメリット RSA暗号 RSAで使われる鍵 処理手順 暗号化の手順 復号の手順 RSA暗号の数学的背景 一次不定式が自然数解を持つ理由 eとLの関係性 そもそもなぜこの式で元の平文に戻るのか?の数学的根拠 証明パート1 フェルマーの小定理 中国剰余定理 RSA暗号をPythonで 楕円曲線暗号 楕円曲線とは? 楕円曲線の式 楕円曲線における足し算の定義 楕円曲線における引き算の定義 無限遠点 楕円曲線における分配法則と交換法則 楕円曲線の加法を式で表現 点Pと点Qが異なる場合 点Pと点P 同じ点を足し合わせる場合 有限体 有限体とは? 有限体上の楕円曲線 楕円曲線暗号における鍵 ECDH鍵共有 数式ベースでの手順説明

                                                          暗号の歴史と現代暗号の基礎理論(RSA, 楕円曲線)-後半- - ABEJA Tech Blog
                                                        • 【書評】ゼロトラストネットワーク | DevelopersIO

                                                          オペレーション部 江口です。 以前から気になっていた「ゼロトラストネットワーク」の翻訳版がオライリーから発売されました。 https://www.oreilly.co.jp/books/9784873118888/ 早速読んでみたのでレビューしてみたいと思います。 書籍の概要 最近新しいセキュリティの考え方として注目されている「ゼロトラストネットワーク」について取りあげた書籍です。 ゼロトラストネットワークの概念、どのように構成するか、認証をどうするべきかなどを解説し、またGoogleやPagerDutyでの実際のシステムの事例などを紹介しています。 目次 1章 ゼロトラストの基礎 2章 信頼と信用の管理 3章 ネットワークエージェント 4章 認可の判断 5章 デバイスの信頼と信用 6章 ユーザーの信頼と信用 7章 アプリケーションの信頼と信用 8章 トラフィックの信頼と信用 9章 ゼロト

                                                            【書評】ゼロトラストネットワーク | DevelopersIO
                                                          • 7payの不正利用についてまとめてみた - piyolog

                                                            セブンイレブンで開始されたスマートフォン決済サービス「7pay」で、セブン&アイホールディングスは2019年7月3日頃より不正利用が発覚したと発表しました。ここでは関連する情報をまとめます。 公式発表 セブン&アイHD/セブン・ペイ 2019年7月1日 [PDF] セブン&アイのバーコード決済「7pay(セブンペイ)」本日サービススタート! 2019年7月3日 【ご注意ください】ID・パスワードの管理について(削除済み) 7payに関する重要なお知らせ [PDF] 7pay に関する重要なお知らせ 2019年7月4日 チャージ機能の一時停止に関するお知らせ [PDF] 「7pay(セブンペイ)」一部アカウントへの不正アクセス発生によるチャージ機能の一時停止について 2019年7月5日 「7pay(セブンペイ)」に対する不正アクセスの件(第3報)セキュリティ対策の強化を目的とした新組織発足の

                                                              7payの不正利用についてまとめてみた - piyolog
                                                            • [CEDEC]脳の動作クロックは33Hz? 人間のスペックに適合させたゲームの遅延対策とは

                                                              2019年9月5日,日本最大のゲーム開発者会議CEDEC 2019の2日めにバンダイナムコ研究所の森口明彦氏から,「芯(シン)・遅延対策2020 〜ヒトのスペックから導かれる安定性重視とフレームレートのベストプラクティス」と題する講演が行われた。 ゲームの体験で大きな問題になりうる「遅延」については,CEDECでもたびたび取り上げられ,森口氏も何度かCEDECで講演を行っている。遅延はプレイヤーの操作から画面に反映されるまでの時間差のことを指すものだが,今回の講演では,プレイヤー側の事情に踏み込んでどの程度の対策が必要とされているのか,どの程度の対策があれば十分なのかなどについて定量的な分析と考察が披露されたので,そのあたりを中心に紹介してみたい。 ゲームの処理サイクル(左)と人間の処理サイクル(右)。それぞれが一定の周期で処理を進めている 人間に対する視覚や聴覚の処理は小脳の運動中枢の一

                                                                [CEDEC]脳の動作クロックは33Hz? 人間のスペックに適合させたゲームの遅延対策とは
                                                              • 書評:並行プログラミング入門 - Software Transactional Memo

                                                                TL;DR 並行処理を実装する人のこれからのスタンダードになる一冊。買い。 並行プログラミング入門 ―Rust、C、アセンブリによる実装からのアプローチ 作者:高野 祐輝 オライリージャパン Amazon 買ったら思いの外早く届いたのでパラパラと読み始めたら一気に読み終えてしまった。 総評 敢えて雑な喩え方をするなら The Art of Multiprocessor Programming (通称TAoMP本) の内容を薄めてRustやアセンブラや計算モデルを足したような本だった。 日本語の書籍としてはかなり珍しくWait-Free, Lock-Free, Obstruction-Freeの違いなどを適切に論じており、TTAS Lock, MCS Lock, TL2といった日本語では希少な情報が書かれているレアな本である。これらに付いて論じている日本語の本は知る限り (TAoMP本と昔僕

                                                                  書評:並行プログラミング入門 - Software Transactional Memo
                                                                • 「量子」と組合せ最適化に関する怪しい言説 ―とある研究者の小言― - むしゃくしゃしてやった,今は反省している日記

                                                                  最近,量子コンピュータの話題をニュースや新聞で見かけることが増えてきました. その中で気になってきたのが,組合せ最適化と量子コンピュータ(特に量子アニーリング)に関する怪しい言説.私自身は(古典コンピュータでの)組合せ最適化の研究をやってきて,量子コンピュータを研究しているわけではないのですが,さすがにこれはちょっと・・・と思う言説を何回か見かけてきました. 最近の「量子」に対する過熱ぶりは凄まじいので,こういう怪しい言説が広まるのは困りものです.すでにTwitter上には,“組合せ最適化は今のコンピュータでは解けない”とか“でも量子なら一瞬で解ける”という勘違いをしてしまっている人が多数見られます*1. さすがに危機感を覚えてきたので,この場できちんと指摘しておくことにしました. 今北産業(TL;DR) “古典コンピュータは組合せ最適化を解けない” → 古典コンピュータで組合せ最適化を解

                                                                    「量子」と組合せ最適化に関する怪しい言説 ―とある研究者の小言― - むしゃくしゃしてやった,今は反省している日記
                                                                  • 読んでみたら最高だった「クラウド系オススメ技術同人誌」を7冊紹介します #技術書典 - 憂鬱な世界にネコパンチ!

                                                                    2020年4月5日に閉幕した技術書典 応援祭では、たくさんの技術同人誌が頒布されました。 本記事ではAWS・コンテナ・CICDをテーマにしたオススメの技術同人誌を紹介します。 個人的な趣味趣向から、特定領域について広く網羅している本ばかりになりました。 なお本記事で紹介している本はすべてBOOTHから購入できます。 リンクも貼ってあるので、気になる本はぜひ買いましょう。 どの本も1000円か1500円でとってもお安いので、全部買ってもいいぐらいですよ! クラウド破産を回避するAWS実践ガイド いきなり自著の紹介からスタートしますが、『クラウド破産を回避するAWS実践ガイド』ではAWSアカウントのセキュリティについて解説しています。「AWSなんか怖い…」を「AWSなど恐るるに足らず!」に変える本です。AWSは気になってるけど勇気が出ないという人・AWSアカウントは持ってるけどセキュリティが放

                                                                      読んでみたら最高だった「クラウド系オススメ技術同人誌」を7冊紹介します #技術書典 - 憂鬱な世界にネコパンチ!
                                                                    • ターミナル用 UTF-8 テキストエディタを Rust でスクラッチからつくった - はやくプログラムになりたい

                                                                      言語処理系やテキストエディタなどのプログラミングツールが好きなので,その周辺を趣味で触ってます.Vim を Wasm にポートするために Vim の実装を読んだりはしているのですが,フルスクラッチでテキストエディタをつくったことはありませんでした. 今年のお盆はめちゃ暑かったので,引きこもって夏休みの自由工作的に Rust でテキストエディタをつくっていたという話です.普段ターミナルで作業しているので,つくるのもターミナル向けテキストエディタです.最近 vim.wasm で C と TypeScript ばかりだったので,そろそろまた Rust か Go を書きたかったのですが,Go はすでに micro という良さそうなテキストエディタ実装があったので,Rust で書いてみることにしました. まずは Build Your Own Text Editor というガイドを利用して,1000行

                                                                        ターミナル用 UTF-8 テキストエディタを Rust でスクラッチからつくった - はやくプログラムになりたい
                                                                      • 運用出来るWebアプリケーションの作り方

                                                                        はじめに 先日、下記のようなツイートを見つけて、そういえば趣味で個人開発してたときには然程気にしてなかったけど、仕事で運用するようになって先輩たちから学んだり自分で身につけたチップスってちょこちょこあるよねー、とふと思ったので、Webアプリケーション開発に関わるものをいくつかまとめてみました。 特に体系的/網羅的という程でもないですし、最近はFWや色々な仕組みでカバーされてるものも多いですが備忘録として。 Tips 機械が読めるログを作る これは割と重要なのですが、ログは人間が読むものではなく機械が読むものです。それはZabbixだったりDatadogだったりSplunkだったりgrep/awkだったりツールは何でも良いのですが、古の時代はさておき現代ではログは機械が読めることが最重要です。 まず大前提として構造化されている必要があります。言うまでもないですが「フリーフォーマット」のログの

                                                                          運用出来るWebアプリケーションの作り方
                                                                        • 知ってるようで知らないTeXの世界 自分の人生より歴史あるソフトウェア開発をマネジメントする技術 - エンジニアHub|Webエンジニアのキャリアを考える!

                                                                          知ってるようで知らないTeXの世界 自分の人生より歴史あるソフトウェア開発をマネジメントする技術 アルゴリズムに関する大著『The Art of Computer Programming』のため、ドナルド・クヌース先生が組版システム「TeX」を発表して41年。その開発は世界中で活発に続いています。日本語TeX開発コミュニティやTeX Liveチームで活動する20代のエンジニア山下弘展(aminophen)さんに、自分より1.6倍も長生きなソフトウェアをメンテナンスする技術について聞きました。 数式がきれいに組めることで広く知られているTEXTEX(以下、TeXと表記)は、誕生から40年を超える自動組版システムです。 学生時代にレポートや論文でTeXを使ったことがある人も少なくないでしょう。技術系の同人誌でページの見栄えを改善すべく、Re:VIEWなど書籍執筆支援システムの背後で動くTeXに

                                                                            知ってるようで知らないTeXの世界 自分の人生より歴史あるソフトウェア開発をマネジメントする技術 - エンジニアHub|Webエンジニアのキャリアを考える!
                                                                          • npm, yarn による zero install 戦略 - from scratch

                                                                            jsconf.eu 2019 に行ってきました。 特に npm や yarn の今後の話とそもそも Registry をどうしていくか、の話があったのでお知らせします。 そもそも Registry をどうしていくかについては次のエントリで話します。 tink: A Next Generation Package Manager npm の次のコマンドラインツールである tink が紹介されていました。 github.com presentation: github.com video: www.youtube.com そもそも npm の仕組み ローカル依存ファイルを読む (package.json, package-lock.json, shrinkwrap.json) 存在しないパッケージのメタデータをfetchする 木構造を計算して、実行する(npm v3 以降だとflattenする

                                                                              npm, yarn による zero install 戦略 - from scratch
                                                                            • より速い WEB を目指す Next.js / nextjs-make-the-web-faster

                                                                              【Next.js Update!】v12リリースを踏まえ、Next.jsの採用を考える 本発表は以下URLでアーカイブ視聴が可能です。https://youtu.be/KaS3bgz_CA4 イベントページ:https://forkwell.connpass.com/event/228457/

                                                                                より速い WEB を目指す Next.js / nextjs-make-the-web-faster
                                                                              • なぜ HTML の form は PUT / DELETE をサポートしないのか? | blog.jxck.io

                                                                                Intro 10 年ほど前に同じことを調べたことがある。 なぜ html の form は PUT / DELETE をサポートしないのか? - Block Rockin' Codes https://jxck.hatenablog.com/entry/why-form-dosent-support-put-delete 当時は全くの素人で、素人なりに調査はしたが、ほとんどが推測の域を出ない結論だった。 この問題についてあらためて記す。 仕様策定の経緯 表題の通り、 <form> の method には GET と POST しかサポートされていない。 HTTP には他にも PUT や DELETE といったメソッドもあるのに、なぜサポートされていないのかという疑問から始まった。 仕様が決定した経緯は、以下に残っている。 Status: Rejected Change Descriptio

                                                                                  なぜ HTML の form は PUT / DELETE をサポートしないのか? | blog.jxck.io
                                                                                • Edge Side Frontend という新領域

                                                                                  at #ワインと鍋js なぜフロントエンドに Edge Worker が必要なのか、Cloudflare Workers をどう使っていくかみたいな話をしました

                                                                                    Edge Side Frontend という新領域