Forem: 井山梃子歴史館

DeepL and disruptive innovation

井山梃子歴史館 — Fri, 21 Aug 2020 14:37:22 +0000

This post is a translation of a Japanese article by DeepL.

There was a hot discussion around a tweet about using DeepL to write a paper.

みのん

@min0nmin0n

投稿論文でDeepLを使って書いた英文と自力で全て書いた段落を用意して英文校正に出したら、明らかにDeepLベースで書いた方が修正が少なくて衝撃。技術の発達で英語力そのものの壁はどんどん無くなりつつあるので、そもそもの日本語での読み書き、論理的思考能力の重要性がどんどん増している気がする。

10:45 AM - 20 Aug 2020

1911 7028

translation:
When I prepared the English text of my submitted paper using DeepL and the paragraphs I wrote on my own, I was shocked to find that the one based on DeepL required fewer corrections than the other. The barrier to English proficiency itself is disappearing as technology develops, so the ability to read, write and think in Japanese and to think logically is becoming more and more important to begin with.

I see this situation as a disruptive innovation. That is, while the current machine translation output is too rough for those who currently speak English well to use, the vast majority of the rest of the English-challenged population will find it easier to get fluent English through DeepL than to grumble about it themselves.

I belong to the latter. My English is good enough to finally pass the TOEFL screening at CS universities in the U.S. (I can't pass CMU though), and although I can read and write English papers, conversation is challenging for me. But at this level, DeepL generates more natural-looking English sentences.

Of course, DeepL makes some "terrible" mistakes, such as reversing the meaning of sentences or dropping sentences, but these can be corrected by looking at the English text. Moreover, it continues to retranslate automatically as you make changes, so you can keep selecting English snippets that fit your style and have them translated in no time at all. This is quite an extraordinary experience.

On the other hand, there are some arguments against the use of DeepL

早川　智@コロナウイルス対策には正しい情報を！

@francescodamil6

@min0nmin0n ご自身の英語力を高める上でこれはお勧めしません。慣れてくると人間が書いた文章と翻訳ソフトのそれはすぐにわかります。アカデミアで残って行くには、母国でなくても自由に英語が使いこなせるようにならないといけないと院生たちにも話していますが、DeepLに負けるようではまだまだ修行が必要です。

06:28 AM - 21 Aug 2020

1 7

translation:
I do not recommend this to improve your own English. Once you get used to it, you can easily distinguish between human writing and that of translation software. I tell my graduate students that if they want to remain in academia, they need to be able to use English freely, even if it's not their home country, but if they're not as good as DeepL, they still need to learn to use it.

Ryohei Thomas Nakano (MPIPZ)

@luckystrike1984

作文なんてのはね、前後の文脈での単語の組み合わせとか、響きとか、リズムとか、ちょっとしたニュアンスでの方向付けや暗示とか、そういうのが醍醐味なんであってね、それは個人の好みでありアートであり作品なわけだから、機械にそれができるとは思わないし、機械の作品は僕の作品じゃない。

09:23 AM - 21 Aug 2020

0 5

translation:
Composition is all about the combination of words in the surrounding context, sound, rhythm, and slight nuances of direction and suggestion, and that's what I enjoy most about it, and since it's a personal preference, a work of art, and a piece of work, I don't expect machines to be able to do it, and the machine's work isn't my work.

It is exactly the opinion of existing customers in disruptive innovation. For example, it is difficult to go through DeepL when discussing directly at an international conference, and it interrupts the flow of the conversation. There is a session time limit too. Besides, machine-translated texts are dull and boring. It is more important to improve one's overall English ability. This opinion is correct, and indeed they must have survived that way.

However, the situation is changing. This is due not only to internal factors, such as improvements in machine translation technology, but also to external factors, such as the spread of COVID-19, which led to the cancellation and postponement of several international conferences earlier this year. On the other hand, we started to see some online conferences in the summer¹. In this case, voice recognition technology can be used for Internet-based conversations.

For example, this year's interview for Google's employment examination was an English coding interview using Google Meet, and I remember that the function of transcribing the other person's speech in real time was very useful for me to understand English. The same goes for the YouTube subtitle feature. While it's hard to listen to international conferences and tech conference presentations in real time, it's still easy to read the subtitles as they come out. What would happen if we were able to put a translation in the subtitles? I expect that not a few people will use it.

With the advent of DeepL, the acceptance of machine translation has reached a new level. The chances of seeing opinions like the one in the opening tweet have clearly increased. I'm sure they will continue to use DeepL. I believe that more and more new English learners will rely on DeepL. The flood of machine-generated English is bound to grow. As skilled English speakers increasingly interact with such English, we can expect their own standards to change. Perhaps one day, a sentence that is suitable for machine translation will be considered good. After all, English is a language with more non-native speakers than native speakers. The demand for non-native speakers will stimulate the machine translation market, leading to improved translation performance. It will attract non-native speakers and stimulate further demand. Will we ever see a day of disruptive innovation where machine translation outperforms native speakers?

There is a paradoxical concern that the normalization of international conferences online may lead to the anti-globalization of participants due to time zone issues. Attending a 4 a.m. session is an experience I don't want to have again... ↩

DeepLと破壊的イノベーション

井山梃子歴史館 — Fri, 21 Aug 2020 14:36:10 +0000

論文の執筆にDeepLを使ったというツイートが話題になった．

みのん

@min0nmin0n

投稿論文でDeepLを使って書いた英文と自力で全て書いた段落を用意して英文校正に出したら、明らかにDeepLベースで書いた方が修正が少なくて衝撃。技術の発達で英語力そのものの壁はどんどん無くなりつつあるので、そもそもの日本語での読み書き、論理的思考能力の重要性がどんどん増している気がする。

10:45 AM - 20 Aug 2020

1911 7028

自分はこの状況を破壊的イノベーションだと捉えている．つまり，現在英語を十分操れている人たちにとっては今の機械翻訳の出力はアラがあって使用に耐えないのだが，その他大勢の英語弱者にとってはDeepLに通す方が自分でうんうん唸るよりも流暢な英文が，簡単に得られるのだ．

かくいう自分も後者に属する．自分の英語力はアメリカCS大学のTOEFLスクリーニングをようやく突破できるくらい(CMUは無理)で，英語論文の読み書きはできるものの会話は難しい．しかし，それぐらいではDeepLの方が言い回しが自然な英文を生成してくれる．

もちろん，DeepLは文章の意味を正反対にしたり文を落としたりと「ひどい」間違いをすることはあるが，それは英文を見て修正が可能だ．しかも，変更に応じて自動で再翻訳を続けてくれるから，自分のスタイルに合わせて英語のスニペットを選び続けるとあっという間に英文が出来上がる．これはなかなかとんでもない体験だ．

一方で，DeepLの使用には次のような反論もある．

早川　智@コロナウイルス対策には正しい情報を！

@francescodamil6

@min0nmin0n ご自身の英語力を高める上でこれはお勧めしません。慣れてくると人間が書いた文章と翻訳ソフトのそれはすぐにわかります。アカデミアで残って行くには、母国でなくても自由に英語が使いこなせるようにならないといけないと院生たちにも話していますが、DeepLに負けるようではまだまだ修行が必要です。

06:28 AM - 21 Aug 2020

1 7

Ryohei Thomas Nakano (MPIPZ)

@luckystrike1984

作文なんてのはね、前後の文脈での単語の組み合わせとか、響きとか、リズムとか、ちょっとしたニュアンスでの方向付けや暗示とか、そういうのが醍醐味なんであってね、それは個人の好みでありアートであり作品なわけだから、機械にそれができるとは思わないし、機械の作品は僕の作品じゃない。

09:23 AM - 21 Aug 2020

0 5

まさに破壊的イノベーションにおける既存顧客の意見である．例えば，国際学会で直接ディスカッションするときにわざわざDeepLを通すのは大変だし会話の流れを阻害してしまう．セッションの制限時間もある．それに，機械翻訳で生成された文章は無味乾燥でつまらない．それよりも自身の総合的な英語力を高めることが大事なのだ．この意見は正しいし，実際彼らはそのようにして生き残ってきたのであろう．

しかし，状況は変わりつつある．それには機械翻訳技術の向上という内的な要因だけではなく，COVID-19の蔓延という外的要因も考えられる．COVID-19の影響により，今年初めの国際学会の中止・延期が相次いだ．一方で，夏ごろからは学会をオンライン開催するケースも見られ始めた¹．この場合，インターネットに乗った会話に対して音声認識技術を活用することができるのだ．

例えば，今年のGoogle入社試験はGoogle Meetを使っての英語コーディング面接だった．Google Meetでは相手の発話をリアルタイムに文字起こししてくれる機能があり，英語の聞き取りに大変便利だったことを覚えている．YouTubeの字幕機能も同じだ．国際学会やテックカンファレンスの発表をリアルタイムに聞き取るのは難しいが，どんどん出てくる字幕を読み取るのはまだ簡単である．もし字幕に翻訳文を出すことができたらどうなるだろう？少なくない人間が利用すると自分は予想している．

DeepLの登場によって機械翻訳の受容は一つの段階に達したと感じている．冒頭のツイートのような意見を目にする機会は明らかに増えた．彼らはこれからもDeepLを利用し続けていくことだろう．英語の初学者がDeepLに頼るというケースも増えていくと考えている．機械生成された英文の氾濫は拡大していくに違いない．熟練した英語話者もそのような英語と付き合っていくことが増えれば自身の中の基準が変わっていくことは予期できる．もしかしたら機械翻訳に適した文章が良い文章とみなされる日も来るかもしれない．結局のところ英語は非ネイティブスピーカーの方が多い言語なのだ．非ネイティブの需要が機械翻訳市場を活性化させ，翻訳性能の向上につながる．それは非ネイティブ話者を引き寄せ，さらなる需要を喚起するであろう．機械翻訳がネイティブを上回るような，破壊的イノベーションの日は来るのだろうか？

ところで，国際学会のオンライン開催の常態化により，タイムゾーンの問題から学会のローカル化が進むのではないかという逆説的な懸念を抱いている．午前4時のセッションに参加するのは二度としたくない体験だ． ↩

cargo nix-installを作るぞ

井山梃子歴史館 — Thu, 20 Aug 2020 13:20:06 +0000

Cargoは普通Rustのパッケージマネージャとして使われますが，cargo installでRust製コマンドラインツールをインストールすることもできます．
インストールできるツールにはcargo-editやcargo-geigerのようなRust開発を便利にするツールのほか，batやripgrepといった日々使うCLIもインストールできます．

このようにcargo installは便利なのですが，自分はNixを常用しているのでこれらのツールもNixで管理したいわけです．
特に問題となるのが，外部ライブラリへの依存です．
例えば，diesel-cliは(デフォルトで)Postgresqlに依存しているため，cargo installするにはPostgresqlをインストールしなければいけません．
これをnix-envで管理するのは二度手間ですし，nix-shellの場合はGCによって依存先が消えてしまうリスクもあります．

そこで，Nixを使ってRustクレートをインストールするツールcargo nix-installを考えてみました．
概ね次の手順でよいでしょう:

クレートをフェッチする．
crate2nixでNixファイルを生成．
nix-envでインストール

まず初めにクレートをcrates.io(もしくはGitリポジトリ)からフェッチしてあげなければいけません．
次に，Nixでビルドするためのdefault.nixを生成します．
ここでは，crate2nixを使うことにします．crate2nixはRust依存関係を各クレートごとに別々のNixパッケージとしてビルドするので，Nixをビルドキャッシュとして有効活用できます．
最後にNixパッケージとしてビルドしたツールをnix-envでインストールしてあげます．これによってアンインストールもNixで行うことができます．

実装するぞうおおおお

Dockerfileを書かずに(嘘)Nixで圧倒的に軽量なDockerイメージを作成する(539MB->245MB->173MB)

井山梃子歴史館 — Mon, 17 Aug 2020 12:42:18 +0000

Buildpacksの紹介記事の便乗です．

Nixはパッケージマネージャの一種で，決定的なビルドを提供することを主眼としています．この記事では，Nixを使って更に小さいDockerイメージを構築することを目指します．

アプリのビルド

今回は元記事と同じくJavaアプリをビルドしてみます．
Nixはビルドの決定性を維持するために，アプリケーションの依存関係を厳密に追跡する必要があり，これにはアプリケーションの使用しているライブラリも含まれています．
そこで，Nixの世界では各プログラミング言語のパッケージマネージャの情報をNixに渡してあげるツールがよく用いられます．
今回はJavaなので，mavenixを使用します．

まずは，Nivを使ってmavenixをプロジェクトローカルにダウンロードします．

[~/buildpacks/samples/apps/java-maven]$ niv init
Initializing
  Creating nix/sources.nix
  Creating nix/sources.json
  Importing 'niv' ...
  Adding package niv
    Writing new sources file
  Done: Adding package niv
  Importing 'nixpkgs' ...
  Adding package nixpkgs
    Writing new sources file
  Done: Adding package nixpkgs
Done: Initializing

[~/buildpacks/samples/apps/java-maven]$ niv add nix-community/mavenix
Adding package mavenix
  Writing new sources file
Done: Adding package mavenix

次のshell.nixを使ってmavenixがインストールされた開発環境を構築します．Nixではプロジェクトごとの開発ツールをグローバルにインストールする必要が無いのです！

# shell.nix
{ sources ? import ./nix/sources.nix }:
let
  pkgs = import sources.nixpkgs {};
  mavenix = (import sources.mavenix { inherit pkgs; }).cli;
in
  pkgs.mkShell {
    buildInputs = [
      mavenix
    ];
  }

開発環境の起動にはnix-shellを使いましょう．

[~/buildpacks/samples/apps/java-maven]$ nix-shell

これでmavenixが使えるようになりました．mvnix-initでdefault.nixを生成します．default.nixはNixにアプリケーションをビルドする方法を伝えるためのファイルです．今回の場合はmavenixによってMavenアプリ用のテンプレートが出力されます．

[~/buildpacks/samples/apps/java-maven]$ mvnix-init 

  Creating files:

./default.nix

  1. Configure by editing './default.nix'
  2. Create a lock file by running 'mvnix-update "./default.nix"'
  3. Build your project 'nix-build "./default.nix"

このインストラクションに従うとアプリのビルドが完了します．

[~/buildpacks/samples/apps/java-maven]$ mvnix-update
...時間がかかる...
[~/buildpacks/samples/apps/java-maven]$ nix-build --no-out-link
nix/store/ph7mw7lja1i3b8m7lwa1746r297l5bg8-sample-0.0.1-SNAPSHOT

出力されたパスにビルド結果が出力されているのを確認しましょう．

[~/buildpacks/samples/apps/java-maven]$ ls -lh /nix/store/ph7mw7lja1i3b8m7lwa1746r297l5bg8-sample-0.0.1-SNAPSHOT/share/java/
total 18M
-r--r--r-- 1 root root  18M Jan  1  1970 sample-0.0.1-SNAPSHOT.jar
-r--r--r-- 1 root root  137 Jan  1  1970 sample-0.0.1-SNAPSHOT.metadata.xml
-r-xr-xr-x 1 root root 1.4K Jan  1  1970 sample-0.0.1-SNAPSHOT.pom
-r--r--r-- 1 root root   72 Jan  1  1970 sample-0.0.1-SNAPSHOT.properties

ローカルで起動することもできます．

[~/buildpacks/samples/apps/java-maven]$ nix-shell -p jdk # OpenJDKを一時的にインストール
[~/buildpacks/samples/apps/java-maven]$ java -jar /nix/store/ph7mw7lja1i3b8m7lwa1746r297l5bg8-sample-0.0.1-SNAPSHOT/share/java/sample-0.0.1-SNAPSHOT.jar

Dockerイメージのビルド

それでは，このアプリケーション用のDockerコンテナを作成しましょう．これもNixを使うと簡単です！
コンテナ内にJavaを入れたいので，default.nixを修正します．

# default.nix
# This file has been generated by mavenix-2.3.3. Configure the build here!
let
  mavenix-src = fetchTarball { url = "https://github.com/nix-community/mavenix/tarball/v2.3.3"; sha256 = "1l653ac3ka4apm7s4qrbm4kx7ij7n2zk3b67p9l0nki8vxxi8jv7"; };
in {
  # pkgs is pinned to 19.09 in mavenix-src,
  # replace/invoke with <nixpkgs> or /path/to/your/nixpkgs_checkout
  pkgs ? (import mavenix-src {}).pkgs,
  mavenix ? import mavenix-src { inherit pkgs; },
  src ? ./.,
  doCheck ? false,
}: mavenix.buildMaven {
  inherit src doCheck;
  infoFile = ./mavenix.lock;

  buildInputs = [ 
    pkgs.jre_headless
    pkgs.makeWrapper
  ];

  postInstall = ''
    # install java
    makeWrapper ${pkgs.jre_headless}/bin/java $out/bin/java \
      --add-flags "-jar $out/share/java/sample-0.0.1-SNAPSHOT.jar"

    # create /tmp for Spring framework
    mkdir $out/tmp
    chmod 777 $out/tmp
  '';
}

ここでは，buildInputsのところでにJREを追加し，postInstallフックでJavaバイナリを/binに配置しています．また，Springが実行時に/tmpに書き込むのでディレクトリを作成しています．

次の内容でDockerfile.nixを用意します．ハイ，Dockerfileは書かなくともNixファイルが必要なのです．

{ sources ? import ./nix/sources.nix }:
let
  pkgs = import sources.nixpkgs {};
  app = import ./default.nix {};
in
  pkgs.dockerTools.buildImage {
    name = "example";
    tag = "latest";

    contents = app;

    # エントリポイント
    config.Cmd = [
      "/bin/server"
    ];
  }

標準のDockerfileではなく，Nixを使ってDockerイメージを作成しています．Dockerfileでは操作(apt install)を記述するのに対し，Nixを使った場合は内容を記述します．
今回の場合は先程作成したアプリのパッケージ(./default.nix)だけをコンテナ内に持つように指定しています．
ビルド方法はアプリのときと同じです．

[~/buildpacks/samples/apps/java-maven]$ nix-build Dockerfile.nix --no-out-link                                                                                                                                                 
/nix/store/b8l5qssgiylc8yi4f8y2ybz83l4nqbrp-docker-image-example.tar.gz

このイメージはdocker load -iで読み込めます．

[~/buildpacks/samples/apps/java-maven]$ docker load -i /nix/store/b8l5qssgiylc8yi4f8y2ybz83l4nqbrp-docker-image-example.tar.gz                                                                                                 
66dd4ba45ad5: Loading layer [==================================================>]  174.5MB/174.5MB                                                                                                                                           
The image example:latest already exists, renaming the old one with ID sha256:76903c2f6febfd083934876f42a64e0bfd18442e80093b3c1021c97d81a35825 to empty string                                                                                
Loaded image: example:latest

実行してみましょう．

[~/buildpacks/samples/apps/java-maven]$ docker run -p 8080:8080 example:latest

やりました！
サイズも173MBと上出来ですね😎

[~/buildpacks/samples/apps/java-maven]$ docker images | grep example                                                                                                                                                           
example latest 4c866b80b51a 50 years ago 173MB

NixでNext.jsアプリをビルドする

井山梃子歴史館 — Fri, 14 Aug 2020 13:09:54 +0000

この記事では，Nixを使ってNext.jsアプリをビルドします．GitHubにこの記事の内容を実行したリポジトリを用意したのでそちらもご覧ください．
Nixを使う利点は適当にググってください．

まずはプロジェクトディレクトリを作成してgitリポジトリを初期化しましょう．

$ mkdir build-next-with-nix
$ cd build-next-with-nix/
$ git init
Initialized empty Git repository in /path/to/build-next-with-nix/.git/

つぎに，ビルドに必要なツールをインストールします．このプロジェクトでは以下のツールを使います．

gitignore.nix: .gitignoreに応じて必要なファイルをフィルタします．
nix-npm-buildpackage: npm(yarn)プロジェクトのビルドに使います．

nivを使ってインストールします．さくっと入れれてハッシュも自動で計算してくれるのはすごい！

$ niv init
Initializing
  Creating nix/sources.nix
  Creating nix/sources.json
  Importing 'niv' ...
  Adding package niv
    Writing new sources file
  Done: Adding package niv
  Importing 'nixpkgs' ...
  Adding package nixpkgs
    Writing new sources file
  Done: Adding package nixpkgs
Done: Initializing
$ niv add hercules-ci/gitignore.nix
Adding package gitignore.nix
  Writing new sources file
Done: Adding package gitignore.nix
$ niv add serokell/nix-npm-buildpackage
Adding package nix-npm-buildpackage
  Writing new sources file
Done: Adding package nix-npm-buildpackage

それではNextアプリを作っていきましょう．今回はTypeScript + ESLint + Jestのテンプレートを使うことにします．
まずはshell.nixを作ってnpmのインストールされた開発環境を立ち上げます．

# shell.nix
{ sources ? import ./nix/sources.nix }:
let
  pkgs = import sources.nixpkgs {};
in
  pkgs.mkShell {
    buildInputs = [
      pkgs.nodejs
    ];
  }

$ nix-shell
[nix-shell:~/build-next-with-nix]$

テンプレートを展開しましょう．これには少し時間がかかります．

$ npx create-next-app next-app --example https://github.com/vercel/next.js/tree/master/examples/with-typescript-eslint-jest

それでは，サーバを起動してみましょう！

$ cd next-app/
$ npm run dev

> with-typescript-eslint-jest@1.0.0 dev /home/pan/build-next-with-nix/next-app
> next dev

ready - started server on http://localhost:3000
event - compiled successfully

うまくいきましたね．
つぎに，このプロジェクトをNixを使ってビルドします．
まず，next.config.jsを使ってNextの設定を変更する必要があります．

// next.config.js
module.exports = {
  distDir: 'output',
  generateBuildId: async () => {
    return process.env.NEXT_BUILD_ID || 'next-build'
  },
}

ひとつ目の設定はNextの出力ディレクトリを変更しています．これは.gitignoreに含まれないディレクトリを指定しなければいけません¹．
次の設定はビルドを決定的にするために必要です．NextはデフォルトでビルドIDをランダムに生成するため，固定値に上書きしてあげる必要があります．ここではNixから環境変数経由で与えることにします．

次のdefault.nixをプロジェクトルートに作成してください．

# default.nix
{ sources ? import ./nix/sources.nix }:
let
  pkgs = import sources.nixpkgs {};
  bp = pkgs.callPackage sources.nix-npm-buildpackage {};
  inherit (import sources."gitignore.nix" { inherit (pkgs) lib; }) gitignoreSource;
  src = gitignoreSource ./next-app;
in
  bp.buildNpmPackage {
    inherit src;
    npmBuild = "npm run build";
    extraEnvVars = {
      NEXT_NIX_BUILD = "true";
      NEXT_BUILD_ID = builtins.hashString "sha256" "${src}";
    };
  }

ビルドしてみましょう！

$ nix-build

成功したら，resultフォルダからサーバを起動してみましょう．

$ cd result
$ ./bin/npm run start

> with-typescript-eslint-jest@1.0.0 start /nix/store/wmw2hld9cdfxy7kdggb4qaxk7ravl8a4-with-typescript-eslint-jest-1.0.0
> next start

ready - started server on http://localhost:3000

😁

Dockerイメージを作ることもできます．Dockerfile.nixを次の内容で作成します．

# Dockerfile.nix
{ sources ? import ./nix/sources.nix }:
let
  pkgs = import sources.nixpkgs {};
  contents = import ./default.nix { inherit sources; };
in
  pkgs.dockerTools.buildImage {
    name = "build-next-with-nix";
    tag = "latest";
    inherit contents;
    config = {
      Env = [ "NODE_ENV=production" ];
      Cmd = [ "/bin/npm" "run" "start" "--scripts-prepend-node-path" ];
    };
  }

ビルドしてみましょう．

$ nix-build Dockerfile.nix

作成したDockerイメージはdocker loadで読み込めます．

$ docker load -i result 
Loaded image: build-next-with-nix:latest

実行してみましょう！

$ docker run -p 3000:3000 build-next-with-nix

> with-typescript-eslint-jest@1.0.0 start /nix/store/231hhb2sbpqvcg1y4jsmhzycfwnhnvbn-with-typescript-eslint-jest-1.0.0
> next start

ready - started server on http://localhost:3000

😎👍

なぜかは分かりません． ↩