JJUG CCC 2019 Fallに参加してきました #jjug_ccc

Java 勉強会

JJUG CCC 2019 Fall
JJUG CCC 2019 Fall





10:00-10:45 Head toward Java 13 and Java 14 #ccc_c1

LINE Corporation KUBOTA Yuji @sugarlife
写真撮り忘れた・・・

java 13

  • JEP 350:Dynamic CDS Archives

  Class Data Sharing。共通的なクラスや文字列などを複数プロセスで共有する機能。
  アプリケーション実行終了時にロードしたクラスを動的にアーカイブする
  異常系も含めて全パターンを網羅しておく必要がある。
  きしださんの「Javaの起動時間といかに戦うか」で、でてきたやつだ。

  • JEP 354 Switch Expressions(Preview)

  Switch文は、break、Switch式はyeild。
  breakからyieldに変わり見分けがつくようになった。
  他の言語だと遅延評価になるものあるが、Javaに関しては遅延評価ではない。即、値を返す。

  待望のヒアドキュメント
  stripIndentの動作は、え？あれ？？？と思った。

java 14

  • JEP 358 Helpful NullPointerExecptions

  a[i][j][k] = b.l のようなのでも、どこでnullが発生したのかを明確にメッセージがでるようになった。

  • JEP 359: Records(Preiew)

  乱暴に言うと構造化されたtuplesのようなもの
  Interface、Class、 recordの並びにくるもの

  • JEP 361 Switch Expressions(Standard)

  標準機能へ。現時点では大きな変更点はない。

OpenJDK Forks

  Eclipse OpenJ9のJDK部分、AdoptOpenJDK、Red Hat OpenJDK、CentOS、Shenandoahプロジェクト、Red Hat、icedtea、ubuntu、しっかりOpenJDKの本家に追随しいてることを確認できた。(Amazonは知りません。)

感想

いよいよJavaでもヒアドキュメントが使えるようになる！
けど、  "JJUG¥nCCC¥n"になるのはどれでしょう？を見事に間違えた。
stripIndentの動作を理解してないので、試してみよう。
補足をブログで書いてくれると言ってた気がするが、どこ見ればいんだろう？
sugarlife's blog ？ LINE Engineering？





11:00-11:45 Jakarta EE: Today and Tomorrow #ccc_i2

Oracle  Dmitry Kornilov @m0mus

Jakarta EE 8

  • release

https://jakarta.ee/release/

  • 仕様書

  https://jakarta.ee/specifications

  • 実装したプロダクト

  https://jakarta.ee/compatibility/

Jkarta EE 9の計画

  • 2019/12/9までにデリバリー計画が提出される
  • 仕様書の更新
  • javax.*からjakarta.* package名の変更

  Bigbang or Incrementalはまだ決まってない

  • Minimum Java SE version

  8 or 11はまだ決まってない

  • いくつかの仕様が非推奨になる
  • 新しい仕様は加えない

  例外としてJava SE 8から取り除かれた仕様

感想

Jakarta EE 8、Jakarta EE 9ともに新機能がないし、9の計画もまだだし、Jakarta EEの話を 聞くタイミングとしては寂しい時だったかな。
Jakarta EE 9でも、Java SE 8が最低バージョンになる可能性があるんだ。そこは11に上がるもんだと 思っていた。

13:30-14:15 運用を支えるためのログを出すにはどうするか？ #ccc_m3

齋藤将也 https://twitter.com/wreulicke:title=@wreulicke
f:id:orangeclover:20191126232802j:plain

適切な量

  • ログは保持、検索コストが高いので、多すぎず、少なすぎず
  • INFOレベル以上で
  • 必要なところに仕込む
    • good
      • システム間通信のリクエスト、レスポンス
      • 業務の関心ごとの対する重要な変更   例えば決済サービスならその決済がどうなったか

    • 重要なロジックの分岐点やその分岐に至った条件

    • bad

      • 関数の入り口
      • AOPで出すと多くなりすぎるし、AOPだけだと業務観点が不足する

意図の伝わる内容

いつ、誰が、どこで、何を どういう動作を行ったか その時のシステムの状態

アプリケーションの特性、要件、コンテキストに併せて、トラブルシューティングに必要な情報

  • どのように対処するかも書くと良い
  • 横通しで検索できる情報

例えば、トランザクションに紐づくID としてリクエストIDを出す 最初のServletFilterでMapped Diganostic Contextを使って付与する レスポンスにもリクエストIDも含める

検索しやすいログ形式

エラーログだけ、特定のAPIのログだけ、1トランザクションのログだけを検索しやすい

より良くするために

感想

トラブルシューティングしてると、どうでもいいログはたくさん出てるのに 肝心なところでなぜ出さない！と思うことが多々ある。
自分で痛い目に合うと気をつけるだけど、痛い目に合わないために、ログのポイントをプロジェクトで 認識を合わせたほうがいい。
盲信せず、議論のたたき台としてはいいんじゃなかろうか。







14:30-15:15 CLRのValueTypeを起点にProject Valhallaを覗いてみる #ccc_c4

日本マイクロソフト株式会社 西川彰広
f:id:orangeclover:20191126232826j:plain

値型

  • メリット

    • 間接参照ではないため、メンバーアクセスが高速
    • スタックを使うので、メモリ確保が速い
    • CPU近傍にデータを配置できる(可能性がある)
    • GCの影響を受けない

  • デメリット

    • 代入時には値の複製が生じる
    • 型のサイズが大きいとき、複数のコストが大きい
    • 継承や多態的な振る舞いを実装できない

Value Type(Inline Class)

  • 「class」と同じように「inline classs」で記述できる

  みんな大好きjavapすると見慣れないdefaultvalue、withfieldという新たなバイトコードを確認できる

  • Object Identityを持たないので最適化しやすい

  できるだけまとめて、CPUの近くのキャッシュに置きたい

  • Javaが.NETの知見を取り込んでValueTypeを検討してる

  例えば、ユーザー定義のデフォルト値は許可しない

マイルストーン

  プロトタイプの開発、検証を繰り返しているため

  • 今は、JDK14ベースのものなら遊べる

いつでるの？

次のLTS(Java 17)は難しそう、次の次のLTS(Java 23)ならどうにかなるかも！？

感想

先はまだまだ長そうだ。 デメリットよりもメリットを享受できるのはどのようなプロダクトだろう？ .NETにも興味をもっと持ってみよう。
C# 8.0のnull許容参照型を学ぶならこれがよさそう。
https://www.slideshare.net/ufcpp/c-80-null
西川さんってマイクロソフトの人になってたのか。





15:45-16:30 Javaの起動速度といかに戦うか #ccc_g5

LINE Fukuoka きしだ なおき @kis

起動速度を求める理由

アプリケーションサーバであれば、起動しっぱなしだったので起動速度は求められなかった。 しかし、マクロサービスでの負荷に合わせた伸縮やサーバーレスでの使われ方だと起動速度が 重要になる。

アプローチ

  • 使いまわす
    • JITのためのプロファイル
      • Alibaba Dragonwell -JWarmup
    • JIT結果
      • OpenJ9
      • Azul Zing - Falcon JIT
  • あらかじめ行っておく

GraalVM

  • GraalVMの話のときは、JIT版なのか、AOT版なのかを区別しないと話が噛み合わなくなるので注意が必要。

まとめ

  • 起動時間、メモリの削減でNative imageが圧倒的に速いし注目されているが、まだ安定していない。
  • トレードオフとして、スループットの劣化、変更しやすさ、使いやすさを失ってしまう。
  • Javaに入っている標準機能でもある程度起動速度とメモリも削減できるので、こちらに着目してもいいのではないか

感想

Java 8と比較して、Java 13で起動速度早くなってるのね。 App CDSでさらに速くできる。 native imageはトレードオフとの兼ね合いだとなるので、当面使う場面には出くわさなさそうだ。





16:45-17:30 多言語対応の仮想マシンGraalVMが照らす未来 #ccc_i6

ヤフー株式会社 阪田浩一 @jyukutyo
f:id:orangeclover:20191126232851j:plain

GraalVMとは

  • あらゆる言語の実行環境となれる能力と機能があるユニバーサルVM
  • ビジョン:パフォーマンスを犠牲にせず、言語間の抽象化をする

GraalVMの構成

f:id:orangeclover:20191126232352p:plain GraalVM JITコンパイラ(以前はここをGraalと言っていた) 以前、GraalとGraalVMってどういう関係だっけ？？混乱してた。

GraalVMで動作する言語

f:id:orangeclover:20191126232512p:plain

そうそうこのイメージ。

ネイティブイメージの生成

なんでネイティブイメージの生成が出てきのか？ それは、Oracle Databaseのため。 GraalVMを組み込めば、Javaはもちろん他の言語も使える。 が、そのまま組み込むにはJVMのサイズの大きさ、初期化処理の遅さ、メモリ使用量の大きさがネックだった。 そこでnative image化。 Oracle Database MLE(Multilingal Engine) MySQLもMLE Pluginに取り組んでいる

ネイティブイメージが適切なケース

  • FaaS
  • クラウドで実行する大規模アプリケーションでのリソース削減
  • 頻繁にリリース(再起動)するマイクロサービスのようなアプリケーション

起動速度とビルド速度のトレードオフ

  • 万能な技術は存在しない、技術はトレードオフ
  • 起動時に行うことを生成時にに行うのでビルド時間が長くなる
  • Hello Worldで1分超かかる

感想

GraalVMがなんでネイティブイメージの生成と関係してくるのか結びついてなかった。 Oracle Database MLE(Multilingal Engine)は聞いたことあったけど、そこから生まれたのか。 なるほどね。





17:45-18:30 DIコンテナ入門 #ccc_g7

TIS株式会社 うらがみ @backpaper0
写真NG

https://backpaper0.github.io/ghosts/dicontainer/#1

まとめ

  • DIとはごく普通のクラス設計の手法
  • DIコンテナは依存関係を考慮したインスタンス構築を助けるもの
  • ボイラープレートなインスタンス構築コードを省略できる
  • ついでにスコープとAOPが付いてきて嬉しい
  • コンストラクタインジェクションがオススメ

感想

DIコンテナとはなんぞや！と言われたらこれ読んでで済むね。 裏面も気になる！





資料

.NET Conf in Tokyo 2019に参加してきました #dotnetconf

.NET 勉強会

f:id:orangeclover:20191119214932p:plain

2019/10/27(日)に開催された .NET Conf in Tokyo 2019の参加レポートです。遅っ
危うく前日の10/26(土)に品川に行くところだった。
.NET関連は初めて参加した。
.NET Core 3.0だからLinux中心か？と思ってたぐらい.NETは疎い。
Visual Studio 2019と.NET Core 3.0が普通の組み合わせなのね。






What’s New in .NET Core 3.0 and Visual Studio 2019 for .NET developers

Steve Carroll

資料

.NET Growth Continues

f:id:orangeclover:20191119215632p:plain

スポンサー

.NET FoundationのコーポレートスポンサーにAWSが参加

Miscroservice

f:id:orangeclover:20191119215829p:plain

ASP.NET Core 3.0

f:id:orangeclover:20191119215907p:plain - gRPC
- Woker Service
- WebAPI + Identity

C#8.0

f:id:orangeclover:20191119215929p:plain

  • null許容参照型
  • 非同期ストリーム
  • 範囲アクセス
  • パターン ベースな using
  • readonly 関数メンバー？
  • using ステートメントの改善

Xamarin

f:id:orangeclover:20191119220012p:plain

Blazor

f:id:orangeclover:20191119220035p:plain

ML.NET

f:id:orangeclover:20191119220054p:plain

.NET 5

f:id:orangeclover:20191119220113p:plain .NET Framework、.NET Core、Xamarinと3つに別れていたランタイムとライブラリが.NETで一本化する

.NET Schedule

f:id:orangeclover:20191119220130p:plain

バージョン リリース予定 LTS
.NET Core 3.1 Dec 2019 LTS
.NET 5.0 Nov 2020
.NET 6.0 2021 LTS
.NET 7.0 2022
.NET 8.0 2023 LTS

.NET Core 3.1が2019/11から2019/12に延びたらしい。 2年ごとの偶数バージョンがLTSになるのね。

Visual Studio 2019 for .NET devs

  • Visual StudioとVisual Sutdio Code で Live Share
    • ソース画面の共有
    • 定義元へのジャンプ
    • co-editing
    • co-debugging

Viusal StudioとVisual Studio CodeでLive Shareで共有。

将来Language Srever Protocolのように、エディタ、IDEで跨って共有できるようにプロトコルが できたら面白いんだけどな。

Code fixes and refactorings

configure

Visual Studioのデモを生で見たの初めてだ。 動かしてるのを見るとそうやって使うのねと感心する。





.NET の今と今後に思うこと (Tokyo Ver.)

Akira Inoue (@chack411)

資料

Windows DNA？

https://www.itmedia.co.jp/help/howto/win/win2000/0007special/complus_vb/chap1/08.html

.NET Frameworkが出る2002年よりも前。com中心の世界。

One ASP.NET

コンパクトにプラがブルにOSに依存しないようにする流れ

.NET オープンソースの道のり

.NET foundation

  • 今年はawsがコーポレートスポンサーとして参加

.NET Application Models(.NET Core 3.0)

.NET Framework の今後について

  • .NET Framework 4.8が最後のメジャーバージョンとなる予定 マイナーバージョンは変わる可能性はある。
  • サポートライフサイクルポリシーの変更はなし インストール先のWindows OSと同じライフサイクルポリシーと同じ
  • .NET Coreが主流となってきた
  • 既存は、.NET Frameworkベースはそのまま利用可能
  • 新規開発の場合は.NET Coreを推奨

Visual Studio App Center for .NET Core 3.0 Windows Apps

WPF、Win Fromsなどデスクトップアプリの機能は停滞していた。 裏では、.NET Core側へ移行していた

  • App Center
    App Centerで配布用のアプリの作成、配布できる 配布対象グループの人にメールが届き、使う人は、App Centerからダウンロードして、インストールできる

  • WPF、Win Formsでcraashレポート、テレメトリーがとれるようになった。
    実行環境、バージョンなどが取れるようになった

Windows Forms とWPFのオープンソースモメンタム

プルリクが増加、今まで見えなかったバグの見るかと対応の速さもOSS化もメリット

APS.NET Core 3.0 Blazor

ブレザー

  • C#で作ったWebAssemblyをブラウザで動作させる
  • JavaScript(Angular、React、Vue)を知らなくてもOK
  • 全部C＃で作れる

  • rezor構文

  • 2種類

    • Blazor サーバアプリ

      • サーバサイド

      • 拡張子.razorでcssとは分ける

      • .NETのアセンブリとしてコンパイルされる
      • フロント側の処理としてはJavaScriptは存在してる(ユーザーが書く訳ではない)
      • サーバとブラウザがWebSocketでやり取り
      • Visual Stduioでデバッグできる
      • 再利用したいものはRazorのライブラリでコンポーネント化しておく

    • Blazor WebAssembly App(2020/5予定)

      • Visual Stduioでデバッグできない、ブラウザのデバッガー

Programinng

アルゴリズムと入力から答えを求める

Machine Learnig

答えと入力からアルゴリズムを求める

APIを使うように機械学習を使う

ML.NET

  • ML.NET Model Builder
  • AutoMLである程度最適なアルゴリズムを検出してくれる
  • 生成されたモデルもzip形式でアプリケーションに組み込まれる
  • 例 感情分析

Introducing .NET 5

  • 別れていた実装部分を統一
  • .NET Core/Xamarionのアプリケーションモデルは全サポート
  • .NET Frameworkからは.NET 5では含まれないアプリケーションモデルもある
    • APS.NET Web Forms→Blazorへ置き換え
    • WCF → gRPC へ置き換え
    • WF → Open Soure core workflow for windows workflowへ置き換え

.NET スケジュール

  • .NET Core 3.1 Dec 2019

NovからDecにずれ込んでいる

まとめ

  • この10年はクラウド革新・・・今後は？

  • 技術を塩漬けするリスクと最新技術を使う意味

    • 今使えるから塩漬けすると、5年後、10年後にアップデートすると大変
    • 常に最新化するも大変だが、CI/CD/DevOpsの環境を整えて、最新化していく 最低でもLTS版でアップデートする 10年後も最新版を保っていく

  • .NETを使い続けたいなら"今"に目を向けよう
    .NET はOSS、コミュニティベースで開発している、開発に参加することで、エコシステムがより盛り上がる

Life runs on Code
It's agrate time to be .NET Developer





.NET Core 3.0 + Windows 10 で WPF 開発

Kazuki Ota (@okazuki)

資料

今日のゴール

  • 最新WPFの状況把握
  • Windows 10 + WPFで開発できること

WPF

  • Windows Presentation Foudation
  • 3.0から登場
  • イマイチ流行った印象がない
  • WinFormsが強い
  • Visual StudioがWPFで作られている
  • XAMLベース
  • 見た目を柔軟にいじれる

.NETの今後 WPF的には

  • .NET Frameworkで今後考えられること
    • 対応しないライブラリの登場
    • C#の最新言語仕様に対応しきれない

.NET Coreへいくメリット

  • ランタイム込みでデプロイにも対応(バージョン問題を解決できる)
  • シングルバイナリ(EXE)での提供

.NET Coreへいくデメリット

  • サポートライフサイクルが短い
  • Windows組み込みではないので、ランタイムの更新は考えないと行けない セキュリティアップデートなど

.NET Frameworkから.NET Coreへ移行

移行ドキュメントを読め

.NET Frameworkからの移行時の苦しみ

Windows 10対応

Windows 10のAPIも呼べる

  • Microsoft.Windows.SDK.Contracts Packageをインストールすれば可能
  • 以前に比べて格段に楽にできる

サポートされているWindows 10 API

  • すべてのWindows 10 APIをサポートしてるわけではない

  • リストが確認できる

  • サポートされているAPI

    • DualApiPartitionAttributeがついているAPI
    • Windows 10 のMSIX形式に固めたアプリだけで使えるAPI

MSIX

Visual Sutdioにパッケージ化する機能がある Windowsアプリケーションパッケージプロジェクト

更新

  • 次回起動時にチェックして、次々回時に更新するのがデフォルトの設定
  • 更新しないと起動しないようにも設定できる

XMAL Islands

https://docs.microsoft.com/ja-jp/windows/apps/desktop/modernize/xaml-islands

参考

https://github.com/dotnet-presentations/dotnetconf2019/blob/master/Technical/Modernizing%20.NET%20Desktop%20Applications%20with%20.NET%20Core.pptx





Inside FastEnum

Takaaki Suzuki (@xin9le)

資料

高速化

速いものを使う

Enum is too late

FastEnum の方が20万倍〜30万倍速い

Static Type Caching

  • 静的コンスタラクタ 一度だけ動くことが保証されるので、排他不要

Unsafe.As

同じメモリ領域を別の型で参照することができる Cのポインターのキャストみたいだな。

感想

性能改善はナノ秒のオーダーなのか。恐れ入りました。 いつか言ってみたいセリフ。 「会社ではなく世界に貢献しているです。」 「早すぎて測定できない」





C# 8.0 非同期ストリーム

Nobuyuki Iwanaga (@ufcpp)

資料

  • C# 8.0 非同期ストリーム

非同期ストリーム

C# 8.0の残りの大物が非同期ストリーム。それを今日説明する。
「複数のデータ」という点が非同期メソッドから非同期ストリームへの変更点

  • awaitとyieldの混在:複数のデータを非同期に返す
  • await foreach:複数のデータを非同期に受け取る

非同期ストリームの例 gRPC

C# 8.0の言語構文・ライブラリ的な説明

  • 非同期メソッドの拡張
    • awaitとyieldの混在
    • async修飾子を付ける
    • 戻り値はIAsyncEnumerable型
  • 非同期foreach
    • await foreach (var x in asyncStream)
    • IAsyncEnumerable (と同じ名前のメソッドを持つ型)を受け付ける
  • (おまけで)非同期using
    • await using (var x = asyncResource)
    • IAsyncDisposable (と同じ名前のメソッドを持つ型)を受け付ける

要求されるフレームワーク

  • .NET Standard2.1/.NET 3.0では標準提供 最近のMSの方針としては基本的に古いバージョンへのバックポートはしない。 非同期ストリームだけは例外。下位バージョンにもNuGetパッケージで提供

Task周りの歴史

Taskクラス初期導入から非同期ストリームまでC#がおかれている当時の 背景も踏まえての説明。





Unity Trackの資料

Clean Architecture for Unity

https://www.slideshare.net/monry84/clean-architecture-for-unity

MagicOnion〜C#でゲームサーバを開発しよう〜

https://www.slideshare.net/torisoup/magiconionc

Riderはいいぞ！

https://speakerdeck.com/ryotamurohoshi/riderhaiizo

C＃×LLVM=アセンブラ!? 〜詳説・Burstコンパイラー〜

https://learning.unity3d.jp/3973/
講演動画もあり。





他の方の感想・まとめ

登壇者ブログ

参加者グログ

Twtiterまとめ

https://togetter.com/li/1422801

「JJUG ナイトセミナー Java O/Rマッパー特集」のメモ

f:id:orangeclover:20170731235413p:plain

【東京】JJUG ナイトセミナー 「Java O/Rマッパー特集」 7/26(水)開催 久しぶりの勉強会。久しぶりのOracl。実は会場に参加したのは初めだったJJUG。

メモ書き。

比較

機能 JPA MyBatis Doma Reladomo
マッピング テーブル ResutlSet ResultSet テーブル
SQL 書かない 書く 書く 書かかない
(書こうと思えば書ける)
設定 アノテーション 　 XML or Javaクラス + xml
アノテーション or SQLファイル
DSL

25分でわかるJPA

資料

ここがスゴイ！

  • DB製品に依存しない操作が記述できる
  • 1対多のようなリレーションを表現できる
    • @OneToOne
    • @OneToMany
    • @ManyToOne
    • @ManyToMany

ここがダメ！

  • DB製品には依存しないが、JPAの実装に依存する部分がある
    • JPQLが発行するSQLは実装依存。
      • Hibernate、EclipseLinnkでは全く別物になる
    • LAZYフェッチでrollback後の動きで差異がある
      • Hibernateだとエラー、EclipseLinkだと検索できるときもある

その他

  • エンティティの状態遷移が重要 f:id:orangeclover:20170731235405p:plain
  • merge()は、引数自体はMANAGED状態にならないので注意
  • フェッチは基本LAZY
  • JPAを使っていい条件(AND)
    • DBを新規に設計できる
    • 集合演算やFROM句での副問合せなど、複雑なSQLは要件的に少ない
    • 「パーフェクトJava EE」を読破した人がプロジェクトに1人以上いる

次に

MyBatis を利用した Web Application 開発についてのご紹介

資料

ここがスゴイ！

  • どんなスキーマでも使える
    • 主キーがなくても大丈夫
    • MyBatis前提でない既存のDBでも
    • サブクエリなどの複雑なクエリも書ける

  • (クエリが自動生成ではなく自分で書いてるので)発行されるクエリが人間に読みやすい

    • O/Rマッパーだとどこでクエリが生成されてるのか、どういうクエリが実行されているのかを意識しながらレビューするのはつらい
    • Site Reliability Engineerの人が横断的にクエリをレビューする
    • Github Enterpriseで検索、どこで動いてるかをすぐに検索できる

  • DBのパフォーマンスを最大限活かすSQLを書ける

    • 自社サービスなら別DBへの移行なんてめったいにしないから

ここがダメ！

その他

次に

ざっくりわかるDoma

資料

ざっくりわかるDoma

ここがスゴイ！

  • コンパイル時にコード検証、コード生成
    • タイポなどつならないミスは、実行時ではなく、コンパイル時に検出できる
    • ドメインクラス(Domaで扱える値オブジェクト)で引数や戻り値の型をチェックできる
  • 他のJARに依存しない
  • ページネーション、悲観排他ロックなどRDBMSの差異を吸収
  • Java 8以降に対応
    • 日付を扱う場合にLocalDateが扱える
  • 2 way SQL
    • バインドなどをコメント形式で行うので、SQLファイルの中身をコピペしてクエリ発行できる
  • エラーメッセージ、ドキュメントなど日本語で手厚いサポート

ここがダメ！

  • SELECTクエリの自動生成ができない
  • 親子などの構造を持ったエンティティへのマッピングができない
  • エラーメッセージ、ドキュメントなどが現状日本語のみ

その他

次に

Reladomo入門

資料

ここがスゴイ！

ここがダメ！

  • 情報が少ない

その他

  • 読み方は「リラドモ」
  • Relational Domain Object の略

次に

実際になにを使っているか？

JPA > MyBatis > Doma > JDBC直呼び

関連

git logをctrl+cで終了すると、それ以降のコマンドが表示されないの続き

f:id:orangeclover:20170301214430p:plain

Conemu+Gitのbashでgit logをctrl+cで終了すると、それ以降のコマンドが表示されないの続き。
疑問は残ったまま。

発端

そうね、Linuxだとqで止めてるんだけど、Windowsだと、たまにCtrl+cに指が動いてしまう。

これ書いていて気づいた。 Git Bashって、Gitインストール先\bin\bash.exeじゃなくて、Gitインストール先\git-bash.exeなのね。

mintty と書いたのは、Git Bashで、Gitインストール先\bin\bash.exeのこと。 なので、改めて確認。

git-bash.exeとbash.exeでCtrl+cで止める

スクロール待ちになっている状態のgit logと普通に起動したlessに対して、
Ctrl+cで止める。

ターミナル git log less
git-bash 終了して、それ以降のコマンドも正常に表示される 終了しない
bash 終了して、それ以降のコマンドは表示されない 終了しない

bashだと発生する。conemu関係なかった。

kill -INTで止めるとどうなるか？

スクロール待ちになってる状態のgit logと、git logから起動したless対して
kill -INTで止める。

ターミナル git log less
git-bash 終了して、それ以降のコマンドも正常に表示される 終了しない
bash 終了して、それ以降のコマンドも正常に表示される 終了しない

送信するシグナルの確認

git-bashでもbashでも、stty -aの実行結果はintr = ^C;なので同じはず。

疑問

killで指定したプロセスに対してSIGINTだと問題ないということは、
bashでCtrl+cでプロセスグループに属する全プロセスに対して送信するとダメのか？
そこに、Git bashとbashの違いがあるのか？
分からん。だれか教えて。

Conemu+Gitのbashでgit logをctrl+cで終了すると、それ以降のコマンドが表示されない

現象

ConemuのGit for WindowsのBash上で、git logを実行しCtrl+cで終了すると、それ以降の
入力したコマンドが表示されない。
コマンドは実行されて、標準出力、標準エラーは表示される。

Git for WindowsのBashとは、gitインストール先\bin\bash.exeのこと

再現手順

  1. ConemuでGit for WindowsのBashを開く。
  2. git log、git diffなどを実行する。
  3. 2.の出力表示が2ページ以上で、スクロール待ちの状態にする。
  4. Ctrl + cで2.のコマンドを終了する。
  5. 何らかのコマンドを入力して、Enterで実行する。 f:id:orangeclover:20170222212313g:plain

発生しない条件

  • ConemuとGit for WindowsのBashで、Ctrl +Cの代わりにqで終了した場合は、問題は発生しない
  • ConemuとGit for WindowsのBashで、lessを使用した場合は、そもそもCtrl+Cでの終了を受け付けない
  • Git for Windowsに付属するGit Bash(mintty)上では、git log、git diffをCtrl+cで
    終了しても問題は発生しない

環境

  • OS
    Windows 10 バージョン1607(ビルド14393.693)
  • Git
    git version 2.11.1.windows.1
  • Conemu
    161206 stable
  • CoemuからGit for WindowsのBashを起動する設定。
  -new_console:d:C:\Users\clover -cur_console:C:C:\usr\opt\git\etc\git.ico C:\opt\git\bin\bash.exe --login -i

原因

分からない。
Git bash(mintty)で発生しないということは、Conemuの問題なのか？

実験

復旧方法の実験

コマンド 結果
clear 戻らない
echo ^[c 戻らない
reset 正常に戻る
stty sane 正常に戻る

復旧方法

Ctrl + cで終了させてしまい、コマンドが表示でされなくなってしまったら、resetかstty saneを 実行して 端末制御をきれいにすると、コマンドが表示されるようになる。

抑止方法

qで終了させる。 Ctrl + cの終了で正常に終了させる方法はわからない。

参考

Git for Windows 2.xでプロンプトの設定(PS1)にブランチ名と改行を入れるとsyntax errorになる

Git

f:id:orangeclover:20170218215924p:plain

Git for Widnows 2系に上げてから、設定(PS1)にブランチ名と改行を入れるとsyntax errorに
なるようになった。 対処方法がわからなかったので、しばらく、改行を外していて放置してた。

現象

bash: command substitution: line 1: syntax error near unexpected token `)'
bash: command substitution: line 1: `__git_ps1)'

条件

  1. Git for Widnows 2.xを使用してる。
  2. PS1に__git_ps1でブランチ名を設定してる。
  3. PS1に改行(\n)を設定している。

例
export PS1='\w$(__git_ps1)\n\$ '

問題にならない条件

  • Git for Widnows 2.xでも以下の条件ではsyntax errorにならない

    • ブランチ名がない場合
      export PS1='\w\n\$ '
    • 改行の設定がない場合
      export PS1='\w$(__git_ps1)\$ '

  • Git for Widnows 1.xを使っている場合はsyntax errorにならない

  • Linuxで、Gitを使ってる場合はsyntax errorにならない

環境

以下の環境だとsyntax errorになる。

  • Windows 10 1608(ビルド 14393.693)
  • git version 2.11.1.windows.1
  • bash 4.3.46(2)-release (x86_64-pc-msys)

調査

LinuxではGit 1.x、2.xでも発生しないから、Git for Widnowsの問題だろう。
WindowsだとGit 1.xでは問題なかった。
2.xになってから、なにか変更があったっぽい。

ぐぐったら事例は出てきた。
PS1 bash command substitution not working on windows 10

'\n$'を$'\n$ 'にすればいいみたい。

なんで？
Cygwinの事例なら、原因が書いてあった。
Cygwin のプロンプトに Git のブランチを表示する（シンタックスエラーが発生した場合の対策あり）

構文解析でエラー

Cygwin 環境では $PS1 のコマンド置換でシンタックスエラーが出ることがあります。

-bash: command substitution: line 1: syntax error near unexpected token `)'
-bash: command substitution: line 1: `__git_ps1)'
これは改行コード CR を無視する Cygwin 独自のシェルオプション igncr による影響の
ようです。igncr が設定されている場合，$PS1 内で $( ) 形式のコマンド置換の後に
\n が続くと構文解析に失敗してしまいます。バッククォートによる旧式のコマンド置換
ではこの現象は発生しません。

CRが悪さしてるのか。
igncrの設定がGit for Widnows 2.xから変わった？

確認してみる。

Git for Windows 1.9.4の環境

 $ git --version
 git version 1.9.4.msysgit.1
 $ bash --version
 GNU bash, version 3.1.0(1)-release (i686-pc-msys)
 Copyright (C) 2005 Free Software Foundation, Inc.
 $ set -o
 allexport       off
 braceexpand     on
 emacs           on
 errexit         off
 errtrace        off
 functrace       off
 hashall         on
 histexpand      on
 history         on
 ignoreeof       off
 interactive-comments    on
 keyword         off
 monitor         on
 noclobber       off
 noexec          off
 noglob          off
 nolog           off
 notify          off
 nounset         off
 onecmd          off
 physical        off
 pipefail        off
 posix           off
 privileged      off
 verbose         off
 vi              off
 xtrace          off

igncrの項目は無い。無いけど有効になっているのか？

Git for Windows 2.11.1

$ set -o |grep igncr
igncr           off

offだな。

2.xでなにが変更になったかは、確認できず。。。

対処

対処は、Cygwin のプロンプトに Git のブランチを表示する（シンタックスエラーが発生した場合の対策あり）に載っているもののうちの以下の2つ。

  • バッククォート形式にする
    export PS1='\w`__git_ps1`\n\$ '

  • 改行を$'\n'にする
    export PS1='\w$(__git_ps1)'$'\n$ '

後者を選択。

$'\n'ってなに？

BASHより

$'string' の形式を持つ単語は特殊な扱いを受けます。 この単語は string に展開され、
それから ANSI C 標準で仕様が決められている、 バックスラッシュでエスケープされている
文字に置き換えられます。 バックスラッシュエスケープシーケンスは、 (もし存在すれば)
以下のようにデコードされます:

(省略)

  • \n
    改行

vagrant のプロビジョニングでgit cloneがSSHの認証エラーになる

f:id:orangeclover:20151003210200j:plain

やりたいこと

初回のvagrant up、vagrant up --provision、vagrant provisionでの
プロビジョニングでgithubやbitbucketからクローンしたい。

が、エラーになってしまう。
vagrant sshでログインしてからのgit cloneは成功する。
provisionでやろうとするとエラーになる。
なんかWindows版のバグ踏んでるんだろうか。。。
ホストがWindowsでうまくいってる方がいたら教えて下さい。

エラー

==> default: Cloning into '/path/to/repository'...
==> default: Error reading response length from authentication socket.
==> default: Permission denied (publickey).
==> default: f
==> default: atal:
==> default: C
==> default: ould not read from remote repository.
==> default:
==> default: Please make sure you have the correct access rights
==> default: and the repository exists.
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.

vagrantfile

Vagrant provision でも SSH Agent Forwarding するを参考に、 forward_agent、privileged、StrictHostKeyCheckingの設定をしている。

config.ssh.forward_agent = true
config.vm.provision "shell",privileged: false, inline: <<-SHELL
    sudo apt-get install -y git-core
    echo -e "Host bitbucket.org" > ~vagrant/.ssh/config
    echo -e "    StrictHostKeyChecking no" >> ~vagrant/.ssh/config
    git clone git@bitbucket.org:path/to/private/repository /path/to/repository 
SHELL

手順

$ eval `ssh-agent`
$ ssh-add ~/.ssh/id_rsa.bitbucket.org
$ vagrant up --provision

確認したこと

privileged

provisionでidコマンドを実行すると以下になっているので、privilegedの設定は有効になっていて vagrantユーザーで動作してる。

 ==> default: uid=1001(vagrant) gid=1001(vagrant) groups=1001(vagrant)

SSH Agent Fowrdingの設定

vagrant sshでログインしてからgit cloneするとパスワード入力せずに認証できるから、設定は問題ない。

remote: Counting objects: 17370, done.
remote: Compressing objects: 100% (11174/11174), done.

provisionでssh-add -lを実行するとエラーになってる

    Error reading response length from authentication socket.

環境