tech.guitarrapc.cóm

Technical updates

はてなブログPro の更新が失敗したお話

はてなブログはかれこれ 3年になるのですが、毎度更新がひやひやです。他にも同じように感じていらっしゃる方もちらほら見かけます。

はてなブログProの契約を更新した - なか日記

さて、今回もいつも通り はてなポイントを用意して待っていたら

なるほど、何か間違えたかなぁということで見ていきましょう。この記事を書いている時点で切れた状態です。

目次

状態

さて、メールではてなブログPro 停止と来ましたが、管理ページの状態は次の通りです。

メールの停止通知と違い、Pro の機能がまだ残っています。Pro停止と 機能停止は別処理のようですね。おいおい停止されるのでしょう。

はてなブログProの更新は、「更新時に更新分のはてなポイント があれば自動更新」だったと記憶していたのですが、更新条件を間違えたか確認します。

ご利用料金は、はてなポイントでお支払いいただきます。コースごとの利用期間分の先払いとなり、ご利用開始時および自動更新時に、必要なはてなポイントの引き落としが発生します。引き落とし時点ではてなポイントの残額が不足している場合、はてなブログProの機能は利用停止(解約扱い)となります。

あってそうですが....ポイントは 1年分で 8434 ポイントを購入しておいたのですが、間違えたでしょうか?

登録ページから行くと、引かれてませんね。

更新というか再開?

埒が明かないので、はてなブログPro に再度申し込みましょう。

できましたね... なんなんでしょうか。

いい機会なのでツイートもしておきましょう。

確認メールも届きましたが、私の理解がおかしいんでしょうかねぇ..。

まとめ

blog.nakajix.jp

にある通り、事前に はてなポイントを購入しているのだからその時点で更新の意思があるし、先に更新を確定させてくれれば済む話だと思うのですが.... 原因がわかればいいのですが、わからないなら来年は別ブログに行くかもしれませんね。シカタナイ。

F# をLearning F# をかじりながら学んでみる

普段、C# を触ってるのですが、switch 文で苦しい思いをすることがたびたびあります。C# 7.0 リリースはよ、と思いつつもいい書き方ないかなぁと探すといい記事に巡りあうことができます。

www.kekyo.net

単純に switch-case の代替としてのパターンマッチングも十分好きなのですが*1 、複数の値の組み合わせやタプルの名前つけと分解は直感的でもあり好きです。そんなときに、@t_tetsuzin さんから、LINQPad で触れること、Option や Either、Maybe から アクティブパターンなどもっと面白いといわれたのでいい機会なので触ってみようと思います。

私の頭はアクティブパターンのURL 送られてもすぐに理解できるような賢さは持ってないのですよ。

アクティブ パターン (F#) | Microsoft Learn

目次

ごにょごにょ触る環境の構築

C# でごにょごにょコード篇を書いては捨て、値試しつつ書き方とか探すときに使っているのが LINQPad です。LINQPad 自体は伝道師の素晴らしい記事があるのでそちらで。

takeshik.org

takeshik.org

LINQPadで F# 確かにサポートされてました。手元のは LINQPad Premium なのでちょうどよさそうです。

ではまず開発環境を作りましょう。

Visual Studio でのF#

Visual Studio を標準でインストールします。残念ながらカスタムにするのは HoloLens ぐらいのためです。F# ここで入れろ? 自動化してるのでカスタマイズめんどくさいです。却下。

VSのインストール後は、F# Tools を OneGetで入れます。

Install-Package visualfsharptools

これで Visual Studio で F# プロジェクトを触ったりビルドができるようになります。

LINQPad での F#インテリセンス

LinqPad で F# をするには少し前準備が必要です。単純に F# Expression や F# Class にしてもLINQPad エラーが発生します。

インテリセンス実行しようとするところでぐぬぬ

View More Details から詳細エラーをみると、AnnouncementClient が見つからないとのこと

System.ServiceModel.Discovery 名前空間にあるので、System.ServiceModel.Discovery.dll をインポートします。

AnnouncementClient クラス (System.ServiceModel.Discovery) | Microsoft Learn

それでもエラーが出ます。今度は MetadataExchangeClient です。

System.ServiceModel.Description.dll はありません。System.ServiceModel.dll をインポートします。

これで System.ServiceModel.dllSystem.ServiceModel.Discovery.dll を参照に加えました。

無事にインテリセンスが出ました。まずは第一歩です。

LINQPad で dump

個人的に、LINQPad を使う良さの90%は .Dump() メソッドにあります。VS のローカル変数と同様に オブジェクトを覗きつつ次にメソッドをつなげることもできるので、ひじょーに強力です。

ただ、F# でメソッド呼び出しは気持ち悪いので、パイプラインから dump を呼べるようにします。

F# は smallCamel ベースのようなので、当初、Dumpではなく dump関数をつくってたのです。

let dump x = Dump x:Object

が、まぁ当然 型情報が失われます。

ジェネリクスどう書けばいいのかなぁ、とおもっていたら inline を使うといいよという情報が。

うまく取れました。

inline って何かと思ったら、型推論しておいて コンパイル時に型確定してその型の分だけ関数を生成するらしい... すごい..。

inline と rec の併用できないんですねー。ほむほむ。

2016/9/4 修正

型注釈...! なるほどキャストとは違うのですね。型推論が強力というか前提というか、ほむほむ。象徴的に感じます。

修正ここまで

さて、もう1つほしいのが、.Dump() のオーバーロードです。.Dump() に名前を付けて表示できるので。適当に書くとエラーが。

むむっと思っていると、Overload はツラいので別名の関数がよさそうとのこと。パイプラインの入力は優先度が低くて後から入ってくるのは PowerShell の ValueFromRemainingArguments も似た挙動ですね。

about Functions Advanced Parameters - PowerShell | Microsoft Learn

適当に書いてみました。

let inline dumpTitle x y = y.Dump(x:string); y

ここで 関数の部分適用 を学びました。なにこれ便利。メソッドでも似たようものですが、変数と関数が両方 let でかけることもあり格段に便利です。

さて、inline でいいかなぁと思っていたら、なんとinline 使わずに普通にかけそう。

ということで最終版

gist.github.com

これで、パイプラインで値を確認しつつ先につなぐことも簡単です。

let dump x = x.Dump(); x

let add x y = x + y
let square x = x * x
let negete x = x * -1
let triple x = x * x * x
let print (x : Object) = Console.WriteLine(x);

square 42 |> negete |> triple |> dump |> square |> print

生きていけそう。

let dump x = x.Dump(); x // let inline dump x = x.Dump; x にするとコンパイル時に利用している型の分だけ関数が生成される (なんちゃってジェネリクス代わりにはなりそう
let dumpTitle (x : string) y = y.Dump(x); y
let titleDump = dumpTitle "れんしゅー"

let hello = "Hello" + "World" |> dump
hello |> dumpTitle "文字列"
hello |> titleDump

チュートリアル

さて、F# といえば、The F# Software Foundation です。

Redirecting…

しかしみてもいい感じの F# Tutorial みたいなサイトはありません。ということで、上からとググって見つけたいくつかを参考に見ていきます。

サイト 概要
言語ガイド - F# | Microsoft Learn 言語仕様です
F# Programming - Wikibooks, open books for an open world Wiki ですが、想像以上にきれいにまとまっていたりサンプルが多いのでいい感じです。
fsharp-cheatsheet チートシートといいつつ、結構ほんとここを参考にしました。
neue cc - F# TutorialをC#と比較しながらでF#を学ぶ 漂白されていません。何気に一番ピンとくるぐらい具体的に書かれています。
文字列 - F# と C# の記法比較 結構知りたい情報あって嬉しいです。
タプル - F# と C# の記法比較 Tuple もここがわかりやすかったです

F# チュートリアル、むむっと思っていたのですが、記事書きつつ見直していて Try F# がプレイグラウンドもあるし最高な気がします。

https://www.tryfsharp.org/Learn

気を取り直して順番に見ていきます。といっても、このあたり と軌跡は似てます。

変数 と関数の 宣言

基本中の基本です。open とかはいったん知らないふりで。

let で変数も関数も宣言できるようです。

let str = "stringだぞ" // System.String 型の変数 str を宣言

C# のvar と同様に型推論効くのですんなりです。末尾セミコロンレス なのですね。代入は不可なのはいいとして、これにさらに = オペレータを使うと比較になるのは少し驚きでした。C# なら ==、PowerShell なら-eq のような比較演算子を別途用意しないのですね。

let str = "stringだぞ"
str = "hoge" // これは比較

2016/9/4 修正

大事なことなのに忘れそう.... 理解しました。

修正ここまで

とりあえず 定番ですね。

printfn "Hello World"
文字列埋め込み

print debug するなりなんでも、文字列へ変換できないことには学習もままならないのです。で、文字列どうやって埋め込むかと思ったら printfn に int埋め込み だと %dとか書くらしく。

printfn "Hello World %d!!" 1

まさか let すると 直でかけないとは...ほむ。

let hello = "Hello" + " World"
printfn "%s" hello

string.Format や Console.WriteLine がかけるということで、もう、こっちのほうが書きやすい..。

Console.WriteLine("Hello World {0}!!", 1)

この時点の気分は完全にこれです。

Boxing かかってもこれでいいんじゃないか気分になったところです。

let print (x : Object) = Console.WriteLine(x);

ここで、sprintfn なんて便利関数があるということでサクッと乗せ換えです。*2

stackoverflow.com

これで、dump 関数につないで生きていけそうです。

sprintf "Hello %s! Number is %d" "world" 42 |> dump
sprintf "Hello %s! Number is %d. %s" "world" 42 "hoge" |> dump

そういえば、型指定は string でもいいのにメソッドの時は String なんですね。

docs.microsoft.com

2016/9/4 修正

System.String と string というより、なるほど用途... 言われないと気付けなかった気がします。

修正ここまで

正直、文字列にちょちょいとデバッグ見たいという時なら、%A でいい感じに自動的に変換してくれるのばかり使いそうな気がします。

部分文字列抽出

さて、続けて部分文字列抽出です。C# なら string.Substring() ですが、 F# はスライシングっぽく書けるようです。便利。

let str1 = "hoge"
printfn "%s" (str1.[0..2])

文字列連結は + と ^ の両方でいけるようで。なんで2つのオペレータがあるんですかね。不思議。

docs.microsoft.com

2016/9/4 修正

なるほど OCaml 由来。

修正ここまで

String の Char 取り出しは、str.Chars(<int>)str1.[0]。ただし .[<int>]だと Char になって .[<int>..<int>] だと string なのは型推論強いけど、うぬぬ。

let str1 = "hoge"
printfn "%c" (str1.[0])
printfn "%s" (str1.[0..1])

2016/9/4 修正

言われてみると .Chars は C# で使ってことなかったです。

修正ここまで

List

List 処理はびっくりでした。正直F# すごい。[] でくくって、; で要素を分割。:: で1つの文字とListの連結 *3@ で合成。

簡単です。PowerShell とか目じゃない。

let list1 = [ "a"; "b" ]
let list2 = "c" :: list1
let list3 = list1 @ list2  

さらに

yield! で List内 List の展開までされてあら素敵。seq や PowerShell 同様 .. でつなげたり、途中の値の指定もできて便利。

なるほど(?)

関数とパイプライン

関数も変数同様 let で宣言できて、引数は 関数名の後ろで指定と。

let f x = x*x
f 2 |> dump

型指定はなるほど

F# といえば、私の中では パイプライン です。*4印象は素直だにゃぁと。これは凄く直感的で使いやすいと思います。ぐいぐいつなげられます。

let add x y = x + y
let square x = x * x
let negete x = x * -1
let triple x = x * x * x
let print (x : Object) = Console.WriteLine(x);

let dump x = x.Dump(); x
let dumpTitle (x : string) y = y.Dump(x); y

square 42 |> negete |> triple |> dump |> square |> print

ということで、List と合わせて触ってみると同じ結果が色々かけるのですが、どれがいいんですかねぇ。

List.map square [0..10] |> dumpTitle "まっぷ"
List.map (fun x -> x*x) [0..10] |> dumpTitle "まっぷ2"
[0..10] |> List.map square |> dumpTitle "まっぷ3"
[ for x in 0..10 -> square x ] |> dumpTitle "リスト内包表記"

あ、リスト内包表記の時だけ、Dump壊れるのなんとかならないでしょうか.... ツラい。

2016/9/4 修正

式が返ってました。[ for x in 0..10 -> square x ] |> dumpTitle "リスト内包表記" でok

修正ここまで

再帰関数は rec キーワードを付けた関数にすると。個人的に再帰の明示は結構好きです。お勉強かねてif使いつつフィボナッチ数列書いてみました。

let dump x = x.Dump(); x
let dumpTitle (x : string) y = y.Dump(x); y

let rec fibonacc n = if n=0 then 0 elif n=1 then 1 else fibonacc(n-1) + fibonacc(n-2);
fibonacc 7 |> dump

なるほど、そのまんまひねりなしでok。

パターンマッチ

先ほどのif..else 連打きもいので導入篇ということで触ってみます。

let dump x = x.Dump(); x
let dumpTitle (x : string) y = y.Dump(x); y

let rec fib n =
    match n with
    | 0 -> 0
    | 1 -> 1
    | n -> fib(n-1) + fib(n-2)
fib 7 |> dump

なるほど簡単。

この先はいずれということで。

www.kekyo.net

Tuple

Tuple とパターンマッチが組み合わさると確かに便利です。Value Tupleが似てるっていうのもなるほど、ほむり。

let dump x = x.Dump(); x

let tuple = (1, "person", "Joeh doe")
tuple |> dump

let hoge tuple1 = 
    match tuple1 with
    | (no, kind, name) -> sprintf "No : %A, Kind : %A, Name : %A" no kind name
hoge tuple |> dump

名前付きで分解されるの便利ですねぇ。

殴り書きコード

いったんおいておきます。

gist.github.com

続き

は、いずれ。

pocketberserker.hatenablog.com

追記

むむっ...。

*1:if-else だと条件最後まで読まないとぐんにょりしますからね

*2:sprintf 遅かったけど、 https://stackoverflow.com/questions/16742189/performance-of-sprintf-vs-string-format 3.1 で40x 爆速になったんですね https://t.co/5qlzKeMkg2

*3:便利!

*4:PowerShell やってたせいでしょうが。

Amazon Route53 の DNS Query Test Tool を使わない手はないお話

このブログに限らず、私は基本的に Amazon Route53 を DNS サービスとして愛用しています。Google Cloud DNS のほうが安かったりとか、いつまでβなんだろうという Azure DNS – サービスとしてのクラウド DNS | Microsoft Azure がありますが、Route53 が好きです。

今回は、 ようやく DNS Query Test Tool が Route53 でサポートされたので、嬉しくて記事を書いてみます。

目次

Amazon Route53 が好きな理由

お名前.com .... はおいておいて、Azure DNS や Google Cloud DNS と比較して Amazon Route53 を使うのにはいくつか理由があります。

  • ドメイン購入も含めた統合
  • Private DNS の管理 との統合
  • 扱えるレコードタイプの種別
  • Aレコードエイリアス (Alias)
  • ルーティングポリシー

そして今回、これらに加えて DNS クエリテストが可能になりました。ざっくり紹介しましょう。

ドメイン購入も含めた統合

Azure DNS も Google DNS も購入できます。

azure.microsoft.com

support.google.com

Amazon Route53 は Route53画面でドメイン購入、管理まで統合しておりわかりやすさは群を抜いています。

個人的には、Azure の Custom domains 管理はDNS の統合という意味では離れすぎているのでなんとかしてほしいなぁと。

Google DNS はちょっとまだまだですね..。

ちなみにグラニでは Route53の有効期限を Azure Functions でSDKを使った定期監視しています。もちろんドメインの自動更新も利用するのですが、どのドメインがいつまでというのがファンクション上でコードで管理され、いつでもテスト可能というのはいいものです。

Private DNS の管理 との統合

Route53 では、指定VPC 用のローカルDNS として Route53 が利用可能です。なかなか使いやすく、Peering越しの DNS 解決を有効にできないようなシーンでも Route53 の Private DNS 機能を使うとおおよそ対応が可能でしょう。

docs.aws.amazon.com

もちろん同名ドメインの パブリックとプライベートがあった場合、プライベートが優先されます。

プライベートホストゾーンとパブリックホストゾーンの両方がある場合、プライベートホストゾーンに関連付けた Amazon VPC の Amazon EC2 インスタンスにログインしていると、プライベートホストゾーンがパブリックホストゾーンよりも優先されます。たとえば、example.com のパブリックホストゾーンとプライベートホストゾーンを作成して、パブリックホストゾーンにのみ www.example.com サブドメインを作成したとします。example.com のプライベートホストゾーンに関連付けられた VPC の Amazon EC2 インスタンスにログインしていると、パブリックホストゾーンにのみ存在する www.example.com を閲覧することはできません。

扱えるレコードタイプの種別

DNS は、扱えるレコードタイプによって制限されるので、利用機会が少なくても「扱える」というのは嬉しいものです。

レコードセット Azure DNS Google DNS Amazon Route53
A
AAAA
CAA × ×
CNAME
MX
NAPRT ×
NS
PRT
SOA
SPF ×
SRV
TXT

2016/9/1時点 の状態です。

クラウドサービス 2016/9/1状態
Azure DNS
Google DNS
Amazon Route53

CAA... さすが Google ですね。

RFC 6844 - DNS Certification Authority Authorization (CAA) Resource Record

Aレコードエイリアス (Alias)

AWS内部リソースであれば、Aレコードエイリアスが利用できます。

シンプルなエイリアスレコードに固有の値 - Amazon Route 53

dev.classmethod.jp

tech.blog.aerie.jp

あくまでもAレコードなのに名前で扱えるのは、CNAME と違って非常に使い勝手が良く、AWSだけで使っている分にはとても嬉しいものです。AWS使っているなら、Route53 を使う大きな理由になるでしょう。

ルーティングポリシー

Route53 には Routing Policy が存在します。あまりやりすぎるとカオスになるので注意ですが、これ1つで単純なラウンドロビンから、重みづけルーティングまで容易に制御できます。

docs.aws.amazon.com

dev.classmethod.jp

とくに Weighted Round Robin は、Blue/Green や CDN のオンライン切り替え、トラフィックの調整まで様々な用途に利用できます。ELB とか ALB いう前に Route53 レベルで様々な制御が可能なのでぜひ利用していただきたいです。

DNS クエリテスト

そして今回 DNSクエリテストが可能になりました。

Amazon Route 53 Announces NAPTR Record Support and DNS Query Test Tool

私の観測範囲が狭いのか、この機能は色々なDNSサービスみてもあまり見かけないように思います。DNS がマネージドだからこそ、そこでどのような状況なのかは日常DNS を触っていて切実なのです。

利用は簡単です。Hosted Zone に移動して、テストしたいレコードを選択してください。

たとえばこのブログは はてなブログPro なのですが、カスタムドメインに対して hatenablog.com を CNAME 設定が必要です。Route53 で設定できているか、簡単にテストできますね。

残念ながら、指定VPC 用のローカルDNSの場合はテストできません。が、十二分に素晴らしいです。ぜひ使っていただけると、もやもやがずいぶんと解消するのではないでしょうか。*1

まとめ

Route53 に限らず、各クラウドプラットフォームのDNS サービスを使うのは非常にいいと思います。ただ、DNS に関しては SSL同様に、使いやすさ、管理しやすさを重視する視点も必要と日頃感じるので、いい感じの使い方を見つけたいと思うのでした。

サブドメインでのゾーンの分割をはじめとして、Route53 活用はサービスの数だけわくわくがあるので使い倒していきたいですね!

*1:私はとてもすっきりしました

目まぐるしい変化を続ける会社 - 一休に行ってみた

このブログでは珍しい会社訪問記事第二弾です。

最近 C# で Windows な会社で良く話題を聞くのは?と聞かれた時に 高級旅館、レストランを中心とした予約ができる一休.comを運営されている 株式会社 一休様 の名前が上がってくることが多いのではないでしょうか。

www.ikyu.com

先日、噂の一休さんに訪問する機会をいただきました。

目次

一休さんとの初めての邂逅

実は昨年(2015年6月30日) に、当時良く一休さんの話題を耳にしていたときに、@kentana20@zimathon さん、@minato128 さんをはじめとするエンジニアの皆様がグラニに見学に来られたことがあります。その時に、「C# で頑張っていきます!」というお話を伺って私たちも頑張っていこうと気合を入れなおしたのでした。当時話題になっていたのが、以下の記事や発表でした。

https://tenshoku.mynavi.jp/it-engineer/knowhow/naoya_sushi/07tenshoku.mynavi.jp

https://tenshoku.mynavi.jp/it-engineer/knowhow/naoya_sushi/08tenshoku.mynavi.jp

speakerdeck.com

speakerdeck.com

会社訪問のお誘い

一年が過ぎる中、一休で取り組まれている様々な改善を耳にしていました。そして、とても嬉しいことに今度は id:kentana20 さんに会社見学へ誘っていただけたので 2016年8月26日 19:00~ グラニのメンバーと一緒に伺ってきた次第です。*1

なんて優しい...!

社内でメンバーを募ったところ、グラニからは、開発メンバー 7名 + インターンに来ている大学生1名 の8名という大所帯で伺うというなんともご迷惑をおかけする事態に....*2 快諾してくださったことに改めて感謝申し上げます。

訪問前の事前準備

さて、伺うとなれば事前情報集めです。何やら新しくされたということで、気になる記事が話題になっていましたね。めもめも。

blog.kushii.net

最近の雰囲気が良く伝わる素敵なブログです。

y-jima.hatenablog.com

あとは勉強会の様子とか。

座談会なので、進行の大枠と質問をざっくりと交換していざ出発です。

訪問当日

19:00 からのお約束だったので 18:30 に珍しく全員が集合完了して出発 *3 六本木から赤坂見附の移動なのですが、ルートがすさまじい回り道感.... ともかく赤坂見附迷路を抜けて出口11から外へ

やってきました。ビル 6F について入口へ。

受付が和風モダンでかっこいい.... 高級ホテルを思わせる安心感があります。

ここから id:kentana20 さんに案内をしていただきました。

期待に違わずこの扉が開いて恐る恐る中に入ります。と、早速入口脇に自販機!なんとゲスト用に無料とのこと...!! id:kentana20 さんのお心遣いで各人が一人思い思いにポチポチします *4

素敵な会議室がいくつもありいい感じでした。

皆様まだ働いていらっしゃるなか、オフィス内を見学させていただき...各開発チームの方とご挨拶しつつ、社内の階段で5Fにも訪問させていただきました。フロアが分かれている場合の社内階段いいですねー、メンバーがわくわく降りて行ってます。フロアが分かれる場合、こういうの大事だと思います。

エンジニアの方の写真は控えたのでツイートを拝借します。

噂の43インチモニターは、噂通り大きい....!! エクセルが捗るとのこと (あれ、プログラミングは...?

話題の CTO @naoya_itoさんにもお会いしました。もしかしてディナーショーを拝見できるかと思いましたが、ちらっとご挨拶で終わっちゃいました。*5

さて、途中の鐘やマグロに心を惹かれつつ 最後に案内していただいたのがリラックスルーム。全社員200名で集まったりもされるとのことで、とても広いのにすごいリラックス感です。まるで、リゾートホテルのライブラリのような居心地の良さがありました。

プロジェクタが3つあるなど 色々説明を受ける横で..。

さっそく座って馴染んでいるメンバー達....*6

という感じで社内を案内していただき、メインの座談会へ。

座談会

広い会議室に通され、うきうきしていたのですが、このあと名刺交換会で名刺を切らす程の一休エンジニアの皆さんに囲まれ戦々恐々となります。

組織に関すること、開発の体制、ブランディング/採用、勉強会の状況からざくっと始まり、テクノロジのトレンド、今後の選択、ロギング、インフラ基盤、モニタリングなどなど座談会では色々なお話を交わしました。

個人的にとても心強かったのは、メイン言語は 今後も C# で行くことに変わりがないというお言葉でした。様々な変化の中で、どうされるのかなと気にしていただけに、今後も負けじと頑張っていきます!

インフラの環境変化といえば、気になるのが..。

Azure、AWS、GCP どれも特徴ありますよねー、という話もしつつ、個人的に GCP を激推しした*7のですが、その日の夜にこんな記事が出てオチ要員の役割は果たしました。記事は不正確なのか、7月中に一部使っただけのようですし今でもポケモンGO はGCP のようです。

今後の選択になんの影響も与えていない雑魚発言で終わりましたが、一休さんがどのクラウドを選択するのかは非常に興味があります。お話の中で、インフラ面でのマルチOS、マルチプラットフォームを視野に入れていらっしゃるのが現実的ですごいと思いました。負けてられません。

あとは、せっかくなので Fastly も激烈に推しておきました。これは正真正銘 Fastly 最高ですからね、*8

まとめ

胸をお借りに行ったのですが、一休さんがあまりに素敵なので今週も月曜から負けてられません。メンバーも刺激を受けているので、今後もコツコツ大胆に開発を続けていきたいと思います。

一休シールいただきました!激かわです!

グラニからも手土産もお渡ししたので、ミッション完了!です。

おまけ

一休マスコットがかわいかったので、絵描きの知人に TiltBrush でVRお絵かきしてもらいました。

上アングル

下アングルも*9

*1:なんと訪問は夜!申し訳ない反面、お心遣いありがとうございます。

*2:ぞろぞろ行ってしまって申し訳ありません

*3:初めてじゃないかしら...ヒドイ

*4:そういえば写真に夢中で押し忘れた

*5:行ったメンバーにファンもいたので残念でした。わたしもファンです。

*6:自重はどうした

*7:GCPを50回は言った気がします、GCP営業に負けないぐらい猛烈プッシュしました

*8:Fastly のみなさんよろしくお願いします(なにが)

*9:少し乱れました。マスコットの質感 VR だと難しいです....

第24回◯◯o◯裏番組シェル芸勉強会 を PowerShell と C# でやってみる #シェル芸

久々のシェル芸です。

Bsh on Ubuntu on Windows でやろうと思ったのですが、手元の環境が入らないのでそっとじ..。

今回は途中で飽きるまでということで、やってみました。

目次

問題

安定の一撃サイトです。

https://blog.ueda.asia/?p=8639

コード全体

今回の回答です。BoUW かなぁと思いつつ、PowerShell がインストールできなかったのでやめました*1

6問まで回答しています。

言語 回答数 環境
C# 1,2,3 問 LinqPad
PowerShell 1,2,3,5,6 問 PowerShell.exe on Windows 10

gist.github.com

回答

縛りは2つ、「ワンライナー」、「ファイル読み込み」、「複数行になっても問題ない」、です。

Q1. Q1ファイルについて、次のような出力を得てください。

Q1 ファイル

玉子 卵 玉子 玉子 玉子 玉子
玉子 玉子 卵 卵 卵 玉子
卵 玉子 卵 玉子 玉子 玉子
卵 玉子 卵 卵 卵 卵
玉子 卵 玉子

出力

玉子:5 卵:1 
玉子:3 卵:3 
玉子:4 卵:2 
玉子:1 卵:5 
玉子:2 卵:1 

PowerShell / C# ともに行ごとに読み取ってほげもげでした。

C# だと、Select して GroupBy して数をまとめて、OrderBy して並びを整えて、Selectで成形した文字列出力です。

PowerShell も同様です。オペレータの挙動が微妙に違うのですが大枠同じです。

Q2. 次のようなテキストについて、繰り返し出てきた文字の2つ目以降を省いて出力してください。

例えばQ2のファイル

へのへのもへじ

の場合、「へのもじ」が正解の出力になります。

これは、C#では .Distinct() を使えば一瞬です。

PowerShell でも同様ですが、2つ一応用意しました。一つはHashtable のキーが重複不許可なことを利用しているのと、同様に Distinct() です。Hashset でもなんでもいいと思いました。

ちなみに using NameSpace を使っていいなら、

using Namespace System.Linq;
cat .\Q2.txt -Encoding utf8 | %{[string]::new([Enumerable]::Distinct([char[]]$_))}

です。

Q3. 第一フィールドをキーにして%%でレコードを区切ってください。
金 日成
キム ワイプ
金 正日
キム タオル
金 正男

というデータを、

%%
キム タオル
キム ワイプ
%%
金 正男
金 正日
金 日成
%%

区切りをテキストで出す意味...は、おいておいてやります。

C# では、初期化変数を用意しちゃいました。なしで書くとどうなるか思いつかない当りできない子です。あと、ずるいと思いつつTuple使ってます。

PowerShell は、awk と同じ要領ですね。

Q4. Q4.xlsxのA1のセルには数字が書いてあります。その数字を出力してください。A4には文字列が書いてあるので余裕がある人はそれも特定してみましょう。

やりません*2

Q5. ファイルQ5について、xに好きな数を代入して各行の式を計算してください。
x + x^2
x + 1/x
x*x*x

余裕のある人は、例えばxに2を代入したければ、

$ echo 2 | ...

というようにecho <代入したい数>から始めてワンライナーで解いてみてください。

echo から初めてと言われた時点で C# はやめて、PowerShell のみで。また、2^2 という構文がないため、Math.Pow(x,2) に書き換えています。

PowerShell の場合、ScriptBlock を Invoke という手と Invoke-Expression を使うのが楽です。C# も似たようなものですね。

今回は Invoke-Expression (iex) を使っています。

Q6. 「玉子」と「卵」の数を数えて、数が少ない方を数が大きい方で置換してください。
卵卵玉子玉子玉子玉子玉子卵卵卵玉子玉子卵玉子玉子玉子玉子卵卵玉子卵玉子卵卵玉子卵玉子

ずるしちゃいました。汎用性がないのであまり好きじゃないのですが。

Q7. 飽きました
Q8. 飽きました

まとめ

C# というか、Linq できれいにつながると楽しいですね。PowerShell でつないでいくよりも可読性が圧倒的に高いのはいいなぁと。

ただ、コードは長くなりがちというのは仕方ないとはいえ感じました。

雑魚回答なので、もっと良い回答をぜひ。

*1:bashではやりません

*2:COM使ったら怒られそうだし。PowerShell はモジュール使っていいなら1 Cmdletでできちゃいます