札幌で開催されたHokkaido.pm #14というイベントに参加し、予想の話（というか予想を支えるシステム設計の話）をしてきました。
内容としては「おとなの自由研究」の取り組みの中で作った南関競馬予想システム「うまミる」のシステム構成と予想ロジック、運用などについてを話したのですが、30分は予想以上に短く、あらかじめ40分で発表枠を押さえておけばよかったというのが正直な感想です。
うまミるについてより詳しく聞きたい方は、アルコールチャンスを用意してくださればお話しますので、是非ともよろしくお願いします。
Hokkaido.pmの皆さん、本当に楽しかったです。ありがとうございました。出来たら11月くらいにもう一発くらい開催してくれたらいいのにな、って思いました！
あと当然ながら、初夏の札幌を満喫したのは言うまでもありません。
Gotanda.pm #18 六本木編で、Core Modulesに寄せてみたら？というタイトルでLTしてきました。
オフィスから歩いていける場所ということもあり、割と早々とLTすることを決めたんですが、勢いは大事ということでLTもどうにか勢いを維持して発表できたんではないかなと自負しております。
「システムプログラミング」というテーマだったようでして、 strace を使ったperlのopenとシステムコールの結びつきについて詳説したトーク（kazeburoさん）や、ネタが被ったと言いながらも、別の切り口によるディープなトーク（skajiさん）、はてなブログSSL化の裏側についてのトーク（papixさん）など、全体的に「掘り下げられた発表」が多かったように感じました。
Mishima.pm #3というイベントが6/3(日)に開催されました。
主催の@dokechinさんが三島在住ということで、数年前から不定期的に開催されていまして、私は #0, #1, そして今回の #3 と、開催されるたびにできるだけ行こうと思っているpmの一つです。
今回の参加者は私を含めて4名。当日の様子は#mishimapmやtogetterにもまとまっていますので、そちらも併せてご覧いただけると雰囲気が伝わりやすいのではないでしょうか。
こちらに発表スライドのMarkdownを置いてありますので、そのままご覧いただくか、reveal.jsで任意のテーマを当ててご覧ください。
かなりポエムっぽいことなのですが・・・
様々な言葉でPerlを貶める人はいるし、私も彼らの言っていることにも一定の理解を示します。確かに一部は事実でしょう。
しかしそれらは大抵、他の言語で鳴らしてきた人が、大して知りもしないPerlについて語っているだけではありませんか？少なくとも私にはそう見えます（私がPerlのすごい人かと言われると、そんなこともないんですけど）し、悲観的すぎるだろうと思います。
そんなことを気にするより、低い理解度でも自分の思った処理を書くことができることの方が大事だと思いますし、Perlにはそのためのツールセットが揃っているんだ、と言いたい。
実は覚えることがかなり少なくて良いので（例えば変数記号については$と@と%を理解できればひとまずOK）、まず書いてみて、足りないところの知識を補いながら少しづつ上達するのに向いている言語なんです。
斜に構えて100%理解した風に振る舞うより、まず手を動かして試すところからPerlを触ってみると、意外といいものだと思えますよ。
・・・スライドからは読み取れないでしょうけど、こんな感じのことを話しました。
私の発表の前に@karupaneruraさんの発表内容が、Perlのコンテキストに関する話題に触れていました。
例えば$age = 100というデータについて、
$age . "歳のおじいさん" という文字列的な扱い$age + 1 という数値的な扱いの両方を同じ変数に対して行えることは、コンテキストを意識することで、一見複雑に思える挙動を理解できるという感じの話でした。
似たようなことをやっている言語はLispやFORTHなどが挙げられます。
この考え方のメリット・デメリットについて書くと長くなるので別の機会に回しますが、Perlについての理解を深める視点として、非常に慧眼だなと感じました。
ytnobodyです。実に3か月ぶりの更新です。ご無沙汰しております。
最近はPerlやサーバサイド、クラウドなどについて、個人的にこれといって真新しいとかすごい、と感じたものがあまりなく、そのため更新が滞っておりました。
また、私の主業務におけるiOSアプリ開発の割合が非常に高くなっており、そちら側のキャッチアップにエネルギーを注ぎまくっている状況でして、これがまた楽しくて楽しくて。
・・・というような事情で、なかなかこちらにはアウトプットできていませんでした。
今日はそんな状況を顧みて、「じゃあ自分がいまどういう哲学に基づいて設計・開発などを行っているかをひけらかしてみたらどうだろうか？」と思い立ち、キーボードをたたいている次第です。
もはや当たり前、と思われる方もおられるかもしれません。まぁしかし、個人のブログですし、お目こぼしくださると幸甚です。
さて、webアプリを公開するにあたって、いくつか「最低限これは必要だよね」というものがあると思います。私の場合、7年ほど前であれば以下のものを挙げたことでしょう。
ここでは「最低限」なので、DBは割愛しました。しかし、こうして見てみると結構多いですね。
では現在はどうかというと、以下のものを挙げます。
だいぶ少なくなりました。減ったものについて着眼していきます。
DNS as a Serviceに取って代わられました。
DNS as a Serviceを利用するにも相変わらずネームサーバの知識は必要なのですが、物理的にサーバを用意したりする必要がなく、クラウドプラットフォームへのログインが可能な状況であれば、いつでもリソースレコードの修正や追加が可能となりました。
Platform as a Serviceに取って代わられました。
これにより、VMや物理サーバの運用をする必要がなくなりました。概念的にはサーバがなくなったことになります。
概念的にサーバがなくなってしまったことによって、ネットワークとその構成機器もまた概念的に不要となりました。
従来これらが賄っていたことはPlatform as a Serviceの一機能として提供されているか、あるいはLoad Balancer as aa Serviceによって代替できるため、必要があればLoad Balancer as a Serviceを追加する程度です。
概念的にサーバがなくなっていますので、OSも概念的に不要となりました。
これはPlatform as a ServiceによってOSが自動的に提供され、かつ更新が行われるようになったためです。
これもPlatform as a Serviceによって不要となりました。
ApacheやNginxなどの複雑なconfigを書く必要がなくなり、PaaS側に組み込まれた機能によって代替できるためです。
Platform as a Serviceに組み込まれているもので十分なので、自分で用意することはやめました。
最近はPHP7に寄せておりますが、JavaやC#、pythonなどもよさそうだと感じます。
デプロイ手段を自前で用意するのもやめました。
Platform as a Serviceがgitに対応しており、tagを切ることでデプロイが行われるように設定しました。
PaaSを使う主目的の一つとしてあげられるメリットですが、その大きさは想定以上でした。
思えば、私が過去にやってきた業務の半分近くが、VM/サーバの管理やOSの管理だったという時期があったくらいですから、従来の半分強のエネルギーで業務が回るようになったと言えます。
OSやVM/サーバもそうなんですけど、一からネットワークを構築して運用することは、それだけで一つの仕事として成り立つくらいに高度かつエネルギーや時間を使う行為です。
また、ネットワークで問題が発生した時には、そのトラブルシュートに必要な知識は専門性が高く、エンジニアのジョブセキュリティが高まってしまいます。そのため、ひとたび問題が発生すると、解決までは帰宅できないという事態が発生します。
OS、VM、ネットワークの管理から解放されるということはつまり、「エンジニアでありながらも、いつも定時で帰宅しプライベートを満喫できる」という状況が、確固たるものになるということではないでしょうか。
httpdの設定は一箇所間違うと、サイト全体に致命的な影響を及ぼすことがあります。ネットワークの問題にも性質が似ているのですが、基本的には「解決しないと帰れない」を生み出す可能性を内包しております。
また、OS同様にセキュリティ上の問題が発見された場合、その対応をするのはhttpdを管理している人間が担当することになります。
これらの管理コストをPaaSに代替させることで、利用料金という形であらかじめ解決しておくことができるのは、不確定要素を予定調和化する上で良い判断だったと考えます。
プログラム動作環境の構築やデプロイをAnsibleなどの構成管理ツールで対応することは、もう3年以上前には行われていたことですが、playbookの作成と管理に心理的コストがかかることをずっと気にしていました。
ところがPaaSを使うことで、プログラム動作環境は毎回お仕着せのものが降って来ますし、デプロイについてはgitレポジトリの特定ブランチにpushするか、tagを切ることで実施されるようになりました。
結果、playbookの管理にかかる心理コストがなくなり、「デプロイをするぞ」という意識から、「pushするぞ」「tag切るぞ」という意識へと移ろい、「デプロイをする」という作業自体がなくなりました。
完全に気にしなくなる状況には至っていないのですが、それでもVMを自分で管理するのに比べて、オートスケール機能が設定されたPaaSの場合は負荷に対する心理的コストが圧倒的に低いと感じます。
もともと私はサーバサイドアプリ(要はwebアプリ）がメインで、インフラを少々嗜む程度のスキルセットでしたが、新しいスキルを習得する余力ができたのは、明らかに従来の業務遂行に必要な時間やエネルギーが半減したからだと考えます。
ここまで書いてきたことは、唯一の判断基準「手間・管理の削減」を突き詰めた結果です。
httpdの項目でも書いた「不確定要素を予定調和化する」ということは、手間・管理を削減するうえでキーとなる考え方ではないでしょうか。
歴史を見ると、「速く快適に移動する方法」として馬や馬車、人力車などが広く利用されていた時代がありました。ところが時代が進むにつれ、馬も馬車も人力車も利用シーンが激減するのですが、その一番の理由は「自動車の普及」でした。
「webアプリを公開する方法」という本質だけを見た時に、歴史や得られたものから考えると、何がより進化したものなのかを思わずにはいられないものです。そして、進化したものはいつも「斬新」で「ミニマリズム」であると、私は考えます。
RAZER Blade Stalth 2017 を購入してから１か月ほどが経過しましたので、レビューしてみます。
※もう１か月使っているので、多少の汚れはご勘弁を。サイズ感が分かるようにコミックを隣に置いてみました。
まず、Windows PCのわりにシンプルで洗練されたデザインが目を引くところでしょう。アルミ削り出しの筐体はブラック（写真）とガンメタリックの２種類から選択でき、背面にはRazerのシンボルがしっかりとあしらわれています。
閉じた状態で厚さは15mmないくらいとかなり薄く、そして1.25kgと、13.3インチPCのわりには軽い部類に入ります。
左から Thunderbolt™3(USB-typeC/電源供給兼）、USB3.0(SuperSpeed)、ヘッドフォン/マイク複合ジャック。USB-typeAの口が欲しい！というケースにもちゃんと対応してます。
こちらは左からUSB3.0(これもSuperSpeed)、HDMI2.0。フルサイズのHDMIポートがあるのは、セミナーなどで登壇する際に非常に重宝します。
ラバー製の足がちょっと汚れてますが、これのおかげでデスクの上で滑ることなく利用可能となっています。ゲーマーにとっては非常に重要なパーツなのでは？
そして見えているファンは吸気ファンとなっていて、排気はスピンドル側にある排気口から出ていくことになります。かなり排熱に気を使った構造です。
ほとんどUSキー配列のMacBook Proと同じようなレイアウトですね。キーボードはMacBookに慣れている方ならばあまり違和感を覚えないような打鍵感となっていますが、幾分フィードバックが強めな気がします。
Macと違うのは、Touchバーがあるはずの場所にファンクションキーが並んでいるところでしょうか。電源ボタンはキーボード上部中央にわかりやすく配置されています。
トラックパッドはほぼMacBook Proと同様の操作感となっており、３本指スワイプの挙動もWindows10からかなりMacOSに寄せてきています。
キーボード両脇についているスピーカーについては、ぜいたくを言わなければ十分納得できるクオリティですが、より本格的なオーディオを楽しみたい場合はRazer TIAMAT 7.1 v2あたりで「Razer寄せ」してみるのがよさそうです。
ディスプレイはQHD（3200x1800）のIGZOタッチディスプレイとなっており、ゲーミングPCを標榜するだけあってハイクオリティです。
キートップはRazer Chroma™と呼ばれるライトアップ機能によって常に七色に光り輝いており（設定変更でカスタム可能）、暗所でもキータイプに支障が出ないようになっています。これこそRazerならではの粋な仕様ですね。
背面のRazerシンボルもグリーンに光ります。
私が利用しているモデルは256GB SSDのものとなります。CPUはIntel Core i7 7500U（第７世代/デュアルコア）、メモリは16GBを搭載。ちょうどMacBook Proの13インチ版に似た性能ですが、メモリだけ倍積んでいる感じになります。
バッテリーは9時間稼働可能ということになっていますけど、実際のところ6時間程度の稼働という感じです。利用の仕方によって多少の前後はありそうですけど、目安としてそのくらいです。
内臓しているグラフィックチップは Intel® UHD Graphics 620 となっており、正直単体ではそんなに期待できるものではなかったのですが、Minecraftをプレイするくらいであれば全然問題ありませんでした。
なお、Thunderbolt™3でRazer Core v2を接続することで、グラフィックボードを外付けできるというキワモノな仕組みが存在します。
そのRazer Core v2ですが、公式サイトによると「 NVIDIA® GeForce® GTX 10 シリーズおよび AMD XConnect™ 対応 Radeon™ RX ボードを含む最新グラフィックスチップセットに対応。」とのことで、MacBookっぽいUltraBookがゲーミングシステムに早変わりするというわけです。
筐体に指紋が付きやすいのが弱点ですが、アプリケーション開発にも耐える硬派なスペック、シンプルなデザイン、美しく見やすいディスプレイと、Web系エンジニアにとって決して悪くない選択であると感じました。
UnixではないというWindowsならではの厳しさがあるかもしれませんが、Unixを手元で触らないエンジニアリングスタイルを確立してしまえば、何ら困ることはありません。Unix/Linuxはクラウドにお任せして、手元ではWindowsを使うというやり方は案外楽なものですよ。ぜひVSCodeとChocolateyをお忘れなく。
え、iOSアプリの開発？それはMacを使ってくださいｗ
遅ればせながら、新年おめでとうございます。
さて、昨年末にAzureの風雲児であるところの@myfinder氏より献本いただきました。改めてお礼申し上げます。ありがとうございます。
2016年11月に出版されたAzureテクノロジ入門2016の改訂版となります。
もともとAzure関連の技術書は数少ないのですが、本書はその中でも入門者・初学者向けの位置付けとして発売されています。索引まで含めて233ページとなっており、定価は2500円と、技術書としてはかなり安価です。
著者陣はほぼ日本マイクロソフトの現任エバンジェリストやアーキテクトなどで占められており、マイクロソフトがいかにAzureというプロダクトを重要視しているかがわかります。
表紙に「Azureを知るための最初の１冊！」「さらに進化したAzure全体像がよくわかる！」と書かれているのですが、まさにその通りの内容です。
そこそこAzureを使っている立場からすると、2章と5章は順序が逆でもいいかもしれないな、と感じました。AzureにおいてはそのくらいにID管理（Azure Active Directory 通称Azure AD, AAD)が肝となりますし、IaaSについてはAzureのPaaS/SaaSについて理解してからフォーカスするくらいでも遅くないと思います。
とはいえ、各章は初学者にもわかりやすいよう図解が多く用いられており、概念を理解する上で非常に心強い一助となることでしょう。すべて通読する必要はなく、手始めに利用する予定のあるサービスに応じて、必要な個所だけピックアップして読むのがおすすめです。ある程度ユースケースをカバーできたら、今度は通読してAzureの可能性をもっと広く学習することができます。
また、ある程度熟練した向きにとっても、次に利用する予定のAzureサービスについて手早く把握しておきたい場合に、辞書のように利用できることでしょう。というのも、本書では各章の要所要所にオンラインドキュメントのURLが記載されており、細かい部分についてはそちらで補完するような構成となっているためです。
あらゆることを正確に記憶しておける人間は稀です。本書は、Azureに関する知の高速道路を読者に提供してくれることでしょう。そして忘れかけたAzureの知見を改めて引き出す際にも十分に価値を発揮してくれると思います。
2017年も終わりを迎えようとしておりますが、2017年はPaaS/SaaSにとって非常にインパクトの大きい一年でした。
このエントリでは、PaaS/SaaS利用者の観点から、2017年を振り返ってみようと思います。
なお、私は主にMicrosoft Azureを利用しているため、内容の濃さなどの面でどうしてもMicrosoft Azure寄りとなりますことをあらかじめご了承ください。
2017年は、フルマネージドDBサービスの利便性が大変向上した一年だったと思います。
特に「DBインスタンス」という考え方から脱却したサービスが登場し、本格的に利用された年だったと言えるのではないでしょうか。
アプリケーション開発者からすると、インスタンスのことを気にするのは本質的ではありません。そのような本質的ではないことについて一切触れる必要なく、DBをサービスとして利用することは、2017年で一気に身近になってきたことだと思います。
また、料金体系的にも「トランザクションごとに課金」というパターンが浸透してきたのも2017年の特徴ではないでしょうか。これによって、真に「利用した分だけ支払う」ことが現実のものとなったと思えます。
スキーマレスなNoSQL DBとして利用でき、各リージョン間でデータレプリケーションが可能なDBaaSです。
もともとAzure Cosmos DBの源流として、Azure DocumentDBというサービスが2010年から提供されていたのですが、Build 2017にて名称をAzure Cosmos DBとし、以下のようなAPIへと対応しました。
料金体系についてはRU(Request Unit)と呼ばれる単位で計上されることになっており、インスタンスベースの課金体系ではないことが非常に重要です。
Azure SQL Databaseで培われてきたフルマネージドDBサービスの堅牢性とスケーラビリティが、MySQLおよびPostgreSQLのインターフェースで利用できるようになったものです。これもBuild 2017で発表されました。
従来であればMySQL/PostgreSQLともにVMを立ち上げ（あるいはオンプレミスのリソースを用意して）そこにインストールし、パフォーマンスモニタリングに気を使いながら、自力で運用するものでした。
このサービスは現時点ではまだプレビューですので、手放しで本番に投入して良いものかどうかは微妙だと思いますが、上記のような運用から解放される道筋が示されていることについて、将来十分に考慮に値することだと思います。
こちらの料金体系は、時間課金のコンピューティングユニットとデータ容量課金のストレージの合算値となり、やはりインスタンスベースの料金体系ではありません。
Amazon DynamoDBは、フルマネージドDBサービスの中でも元祖と言えるでしょう。2012年にサービス提供が開始され、2013年に東京リージョンで利用可能となりました。
リージョン間でのレプリケーション（クロスリージョンレプリケーション）にも対応しており、課金体系もデータ量とスループットに基づいたものとなっています。
これらのことは、近代的なフルマネージドDBサービスの基礎となっており、Amazon DynamoDBがサービスを通して示したビジョンは大変重要なものと言えるでしょう。
上記で紹介したサービスはいずれも、開発者からDBの管理という手間をなくそうという方向性のサービスです。自力でDBの管理を行う場合にかかるコストと、上記サービスを利用した場合のコストは、性質的に全く異なるものです。
また、自力でDBの管理を行う場合は、どうしても人間そのものがボトルネックになってしまいます（腰痛や風邪などの体調不良、冠婚葬祭に伴う休暇など）。速く移動するという本質で見た時に馬車から自動車へと変遷していった歴史があるように、DBの管理やスケーリングについてもより利便性の高い手段を検討していくことが肝要なのではないでしょうか。
そして、開発者がより開発に集中できるようにし、生産性の向上に繋げていくことが、最終的な競争力に寄与するのだろうと私は思います。
以前まで利用していたbitbucket+rijiなブログがいつの間にかbitbucket側のサービス変更の影響で閲覧できない状態閲覧できない状態となっていました。
ですので、ひとまずAzure Web AppsのFreeプランで閲覧できるようにしておきましたので、お暇な方はどうぞご覧ください。
※このエントリはOSS紹介 Advent Calendarの17日目のエントリとなります。
皆さん、Visual Studio Code（以下VSCode）使ってますか？
VSCodeはMicrosoftが開発しているOSSのエディタです。github上で活発にコミットされているプロダクトであり、その使い勝手は比較的Atomに似ていると言えるかもしれません。
今回は、そんなVSCodeのプラグインとして提供されているGit LensというOSSを紹介したいと思います。
簡単に表現すると、git blameをVSCodeで超絶便利に使えるようにするプラグイン、という感じでしょうか。いちいちgithubとかbitbucketに見に行くのもだるいですし、かといってgit blameを毎回手打ちするのもだるい、という向きにこそうってつけのプラグインだと私は思います。
インストール手順ですが、VSCodeのプラグイン管理画面でgitlensを検索するとすぐに出てきます。あとは「インストール」ボタンを押すだけ。
非常に簡単ですね。
とにかく見やすい、の一言に尽きます。以下の画像は、私が個人的に開発しているうまミるのプロジェクトにおけるGit Lens活用の様子です。
Git Lensをインストールすると、左側にGITLENSと書かれたブレードが出てきます。これを開くとブランチ一覧が見えて、その中にはコミットの一覧がずらりとぶら下がっている状態となっています。
コミットを開くと、そのコミットで変更のあったファイルの一覧が表示されます。ファイルを選択すると、上の画像のように差分が見える、というわけです。
他にも、コミットに関する操作なんかも割と細かくサポートされています。
Git Lensは次世代のgit blameと言えるんじゃないかと私は思っております。
AtomにGit Lensを移植できないだろうかというような議論がAtom Discussに上がるくらいには便利ですし、VSCodeを使うなら是非とも利用したいプラグインでしょう。