しばたテックブログ

気分で書いている技術ブログです。

メリクリ

🎄メリクリ🎄

f:id:stknohg:20161224104222p:plain

なにこれ?

bannerコマンドのPowerShell版を作ってみました。

以前シェル芸人たちの間でbannerコマンドが流行ったことがありまして、
(下記リンク参照)

togetter.com

その際に@mattnさんがgobannerというGo言語のbanner実装を作りました。

github.com

で、その実装方法に感銘を受けて、PowerShell版を作ってみたのがコレになります。
実はモノ自体は結構前に作っていて、公開するタイミングを失ってしばらく寝かせていたのですが、今なら良いかなーと思い公開することにしました。

PSBanner

ソースコードはGitHubに上げています。

github.com

インストールはPowerShell Galleryから可能です。

Install-Module -Name PSBanner -Scope CurrentUser

なお、実装の都合*1、Windowsのみでの動作となります。
動作確認はPowerShell 5.1で行っていますが、おそらくPowerShell 2.0以降であれば動くはずです。

基本的な使い方

Write-Bannerコマンドに好きな文字列を食わせてください。
-FontNameパラメーターで表示フォントを、-FontSizeパラメーターでフォントサイズを指定できます。

使用可能なフォント名はGet-FontFamiliesコマンドで取得可能です。

コード例はGitHubに載せているのでそちらを見ていただければと思います。

実装について

基本方針はgobannerの実装を参考にしています。
内部的に指定されたフォントでBitmapを描画し、不透明なドットを#に置き換えるというものです。

一度見てしまうと単純なやり方に思えますが、最初に見たときは「よくこんなこと思いつくなぁ!」と本当に驚きました。

gobannerに対して、フォントの指定は名称で可能なのと、Screen Widthはコンソールバッファの値を使う様に変えています。
あとPowerShellでは文字列以外のオブジェクトの入力もあるため、その辺に対する処理もちょっと入っています。

補足

本エントリはPowerShell Advent Calendar 2016 21日目の代理投稿になります。

*1:System.Drawing.*なクラスを使っているため、System.Drawing.dllのないPowerShell Coreでは動作させることができません

CLR/H #103 ~ クリスマス オブ ザ デッド ~ でPowerShellをふりかえりました

先日、通称カソウ化デイことCLR/H #103 ~ クリスマス オブ ザ デッド ~で「PowerShell 10年間ふりかえり」というタイトルでPowerShellについてお話させていただきました。

clrh.connpass.com

本エントリはPowerShell Advent Calendar 2016 18日目のエントリも兼ねています。

セッション内容について

セッション資料

セッション資料はこちらになります。

30分のセッションでしたが、かなり駆け足で進めてしまったためお聞き苦しいところが多々あったかと思います。
申し訳ありません。精進します。

1. PowerShell 10年間ふりかえり

最初はPowerShellの歴史と機能を追いかける感じの内容にしました。

歴史についてはPowerShell 2.0からですが、最初に新しいOSに標準で組み込まれ、その後他のOSに対してWindows Management Framework(WMF)を提供するというかたちになっています。
このため正確なリリース日を追いかけるのが少し面倒で、資料によってはOSのRTMをもってPowerShellのリリースとしてるものも存在しています。

そして、各バージョンにおける機能の詳細については参考資料に上げたサイト(一部このブログのエントリも交じってますが...)を見て頂く方が良いかと思います。

2. これからのPowerShell

PowerShellはOSSになり、GitterやSlackのチャネルもでき、RFCも募集する様になり情報がオープンになりました。
セッション中では一応予測を立てましたが、正直なところを言うと、実際に生の情報に触れてみるほうが下手な予想より余程役に立つと思っております。

ですので、ぜひ実際にGitHubにアクセスして新しいPowerShellを試す、IssueやGitter、Slackに参加してみてください。
(わたしもできる限りでがんばります...)

PowerShell

github.com

Gitter

gitter.im

Slack

http://slack.poshcode.org/slack.poshcode.org

PowerShell RFC

github.com

3. 誰のためのPowerShell

最後はポエム要素ありと注意書き入れた様に、割と個人的な想いについて述べています。

PowerShellがオープンソース・クロスプラットフォーム化したのと同時に「PowerShell for every system!」という標語が挙げられました。
実際にこれからは色々なプラットフォーム上でPowerShellが動き標語の通りになると思います。
ただ、プラットフォームを選ばなくなったからといってみんなが使うべきものなのか、「PowerShell for everyone」になるだろうか、という疑問がここで言いたいことの原点になります。

この点に関してはPowerShell TeamやMicrosoftとしての思惑もあるでしょうし、人によって答えは変わるかと思いますが、私はPowerShellは万人向けでないと考えています。

理由としては、今のところPowerShellはサーバー管理や自動化といった目的に特化したツールであるという点になります。
目的に特化しているので目的外の利用をしようとすると割とすぐハマりますし、ハマる以上は万人向けではないと思います。
PowerShellの機能自体はかなり強力なので目的外であっても無理をすれば大抵のことはできてしまいます。
頑張れば何でもできるという点をとれば万人向けと言えるかもしれません、が、私としてはそれは無理筋だろうと考えています。

しかしながら、PowerShellは万人向けでないと言いましたが、目的に合わない人はPowerShellに触れるべきではないとまで言う気はありません。

PowerShellは(バージョンを問わなければ)大抵のWindowsに標準で搭載されており、だれでもすぐに使うことが出来ます。
LinuxやMacであってもパッケージ管理ツールから簡単にインストールできる様になりました。

使ってみないと目的に合っているか分からないこともあると(むしろそっちの方が多いかと) 思います。

個人的な想いとしては万人にPowerShellに気軽に触れてほしいと考えています。

ちょっと触れてみて、目的に合えばそのまま使ってほしいですし、合わないと思えば無理をせずにすぐにほかのツール(代替はたくさんあります)に切り替えれば良いと思います。

(補足)PowerShell と Bash

PowerShellの代替のひとつであり、PowerShellとよく比較されるBash on Ubuntu on Windowsについても軽く触れました。
細かい内容については以前に発表したLTの内容をベースとしているので、以下のリンクから内容を確認していただければと思います。

stknohg.hatenablog.jp

(補足)PowerShell と コマンドプロンプト

こちらに関してはかなり誤報が広まってるのであえてセッションに混ぜました。
細かい話はこちらをみてください。

stknohg.hatenablog.jp

最後に

拙い発表でしたが言いたいことは言えたので満足はしています。

他の方のセッションやLTもどれも面白いものばかりで、カソウ化デイ、本当に楽しかったです。

PowerShellで入れ子のクラス(内部クラス)を示すには + を使う話

よく忘れるので備忘録としてメモっておきます。
内容に関してはPowerShell Blogの以下の記事のままです。

blogs.msdn.microsoft.com

PowerShellで入れ子のクラス(内部クラス)を示すには + を使う

PowerShell Blogの例ではNet.WebRequestMethods.Ftpクラスを使っているので本エントリでもそのまま使います。

ソースを見ればわかりますが、このクラスはNet.WebRequestMethodsクラスの内部クラスとして定義されています。

このクラスにPowerShellからアクセスする際は

[System.Net.WebRequestMethods.Ftp]

ではなく

[System.Net.WebRequestMethods+Ftp]

+を使ってアクセスする必要があります。

f:id:stknohg:20161215215253p:plain

何故なのか?

PowerShellの仕様と言ってしまえばそれまでですが、これはリフレクションでの表記をそのまま使用しているとの事です。

例としてC#で以下のコードを呼び出すとFullNameSystem.Net.WebRequestMethods+Ftpとなることがわかります。

// C#
typeof(System.Net.WebRequestMethods.Ftp).FullName

LINQPadで確認した結果)

f:id:stknohg:20161215215822p:plain

まとめ

とりあえずこんな感じです。

この点に関してはPowerShellが悪いというよりはC#(やVB.NET)がよしなにやってくれていると捉えたほうが良いかもしれません。

ちなみにNet.WebRequestMethods.Ftpクラスの他にSystem.Environment.SpecialFolderクラスも内部クラスだったりします。
私はこっちの方をよく使うので、今回もこのクラスでハマりました...