Visual Studio 2019 Launch Event in Tokyo. に行ってきました。 #VS2019

connpass.com

お仕事はもっぱらC#で.NETなのにあまりそっち方面のイベントに参加したことがないことに気付いたりしたので申し込みました。

 大人の事情でお仕事に使っているのはまだ2017ですが、軽くなったとかAIによる入力補完とか楽しそうな情報が流れてましたよね:)

 品川はさっぱり縁がないですね…;

Visual Studio 2019 GA ! ~ 最新情報 & これからの開発スタイル @chack411

タイトル通り、VS2019でサポートされるこれからの開発で利用される機能についてのセッションでした。

最近DockerのWindowsコンテナがマイブームなので、AKSで一部のコンテナだけ(?)自分の開発環境のものを使って他は共有するテスト環境のコンテナを利用できる機能みたいなのが気になりました。

関わっているプロジェクトのDockerfileを勝手に書いたりしていて本番運用できるかどうか考えてみたときに、AWSだとWindowsコンテナが自前で頑張るみたいな感じだったので早々に見切りをつけてしまったのだけれどAzureならうまくできるのだろうか。(そもそもコンテナで運用するほどの規模じゃなさそうという話はあるけれど、半分趣味でやっている。)

 

www.slideshare.net

.NET Frameworkのプロジェクトを.NET Coreにマイグレーションする勘所を実際にやってみて説明していただけるという内容でした。プロダクトコードを使ってデモしていただけるのは具体的にイメージがつくのでとてもありがたいですね🙏🏻

「.NETのメインはもうCoreに移ってる」とのこと。バージョンアップもまずはCoreに入っていくし、複数バージョンが同居できるし、ランタイムごと配布できる。

確かにポータビリティがあるというだけで充分に魅力的ですよね:) 顧客の.NET Frameworkバージョンに縛られていつまでも古いバージョンを使い続けなければいけない苦しみ…肌で感じております…:(

CoreのプロジェクトからFrameworkのプロジェクトを参照していてもビルドできて実行も可能とのこと。ただしFrameworkにあってCoreに無いAPIは普通にあるので実行時に落ちる可能性がある。実際にそのようなAPIが呼ばれるコードパスを通らないと発覚しないので、できればやらない方がいい。

もちろんやらない方がいいに決まっているわけですが、現実的には全てのプロジェクト/ライブラリを同時に置き換えるのが難しいことはあるわけで、そういうところは現実に寄せて実行可能としている姿勢は.NET系の文化としてあるのかなと勝手に思ってます。そういう守るところは守りつつ現実的な妥協(?)もやっていくバランスがとっても良いと感じてます:)

実際にCoreへマイグレーションするのにどれぐらい修正が必要なのかは.NET Portability Analyzerを使うとわかるとのこと。サードパーティ製のライブラリはサードパーティに対応をおまかせするしかないとのこと、そらそうだ。

ところでお話の中でオススメだと言及されていたSimple Injectorが気になるので後日触ってみたい。

 

www.slideshare.net

先述の通り最近DockerのWindowsコンテナがマイブームなので注目だったのですが、知識が足りずにあまり咀嚼できませんでした;

docker-compose/Service Fabric/k8sあたりのオーケストレーション(?)周りはまだ全然触れていないので、個人的な今後の課題ですね。

C# 8.0 Preview in Visual Studio 2019 (16.0) @ufcpp

C#といえば」の岩永さんのセッションでした。C#erの例に漏れず、私も大変お世話になっております🙇🏻‍♂️ブログでも紹介されているC#8.0の新機能についてわかりやすく解説されていました:)

NRT(Nullable Reference Types null許容参照型)はオプションによって有効/無効を切り替えられるとはいえ、原則として後方互換を破壊しないというC#の原則を破ってでも入れたい修正とのこと。(オプションで切り替えるのは構文が分岐するということで複雑性が増すので、それも原則としては避けていたらしい。)

確かに今まで遭遇したことがない機能追加ですよね。とはいえ確かにnullを排除するのはモダンな言語では避けて通れないお話だと思います。私も正式リリースの暁にはチャレンジしたいです:)

とはいえnull許容なライブラリを使った瞬間に許容/非許容が混ざるので、混在するのは前提でnullチェックなどはしていかないといけないとのこと。もともとnullありきで設計されている以上、そこは仕方ないですよね。

インターフェイスのデフォルト実装はランタイムの変更が必要になる機能ということで、これは.NET Framework 2.0(2005年)以来のことだそうです。メジャーバージョンアップにふさわしい機能追加ですね:)

他にもswitch式やそれと組み合わせられるパターンマッチング、null合体代入など嬉しい機能が目白押しですね:) 大人の事情でValueTupleとデコンストラクタすらまともに使えていないですが、正式リリースが楽しみです:)

 じゃんけん大会でステッカーなどもらってお開きとなりました:) MacBook Proにステッカー貼りまくり野郎なのですが、いい加減に空きスペースがなくなってきたのでアップルロゴを隠す形で貼りました;

C#の新機能の話はやっぱりテンションが上りますね^^; 思えばオライリーさんのC#本を読んで触り始めてからずっと好きな言語です。なんというか、カチッとしてるけれども現実に折り合いをつけられる柔軟性を持っているというか…。モダンな機能もどんどん取り込まれますし、Coreの登場で間口も広がりましたしね:)

今後もC#でお仕事を続けていきたいです:) なので自分から環境を変えていこうと改めて思いました。

運営に関わられた皆さん、ありがとうございました🙏🏻

デブサミ2019に行ってきた #devsumi

今年もモチベーションとか色々もらいました:)

例によって印象に残ったセッションを記録です。

Day 1

 Wi-Fi本当にありがたいです🙏🏻

 

GitHub Actionsはどのような未来を描くのか : コンテナ技術が開くワークフローのOSS化 

Speaker Deck @ikeike443

タイトル通りGitHub Actionsについてのお話。

- ワークフロー=アクションの組み合わせ

- アクション=1コンテナ

- アクションの実態はDockerfile

- Dockerでできることは大体はできる

- イベントが色々用意されていて、外からキックすることもできる

- 既に用意されているアクションも色々ある(HTTP叩いたり

楽しそう(小並感。

ベータの申込みをしたので通ったら触りたい。

 

レガシーとのいい感じの付き合い方 〜15年続くウェブサービスのシステム改善パターン〜

自分のお仕事は結構な割合でレガシーとのお付き合いなので、共感と学びが多いセッションでした。

特に「葬り(不要な機能の削除)」が大事というのは本当にそうだと思います。機能が多いということはリファクタリングするにあたって気にすることが多いということで、不要な機能を残すために気を使うというのは労力的にも気力的にも大変苦しいことですよね…。顧客に「不要」だと認めてもらうスキルが必要だと痛感したことがあります。

 あとは「自分たちでコントロールできるインフラがあると進みが早い」というのも大いに共感できます。これがあるとスクラップ&ビルドも簡単で色々な試しができてスムーズですよね。この観点でIaaSがもたらす恩恵は大きいなと感じています。

 

カオス化した組織とエンタープライズシステム群を、モダン化したい!ノンIT企業のシステム企画開発を、ドメイン駆動型に組織ごと変えるまでの道のり

涙なくしては聞けない、素晴らしいお話でした。あるあるすぎて首がもげそうになる。(心を打たれすぎてろくなことを呟いていない…)

9人で9事業をカバーしてたけど21人で4事業にとか、どうすれば可能なんだろうか…。

「運用・問い合わせはイイヤツに集まる」ありすぎて切ない…。

障害が発生すると保守が回らないので保守、障害対応、パフォーマンス改善に体制を分割した。集中が必要な業務と割り込みが発生する業務を兼任するとどうしようもなくなるのでこれは絶対に分けないとですよね。

外部の会社と仕事をするために「俺流」を捨てる。これも本当に大事だと思います、盲目的に世の中の標準に従えばいいということではもちろんないわけですが、標準はなるべくして標準になっているわけですよね。

あとはいろんな情報を数字として出せているのがすごいですね、見える化ができている…。

ドメイン駆動で「価値の低いドメインは放っておこう」という判断になるのは先程の「葬り」と似てますよね。優先順位をつけるのとやらない判断をするのは本当に大事だと思います。

(C#の会社らしいので個人的にちょっとシンパシーを感じました)

 

「ITエンジニアに読んでほしい!技術書・ビジネス書大賞 2019」プレゼン大会

割と毎年参加しているので今年も:)

もちろん全部の本が良書なのだと思いますが、個人的に刺さったのは「イシューからはじめよ」の「それは本当にイシューなのか?」という問いかけです。

他のセッションでも出てくる「不要な機能」「価値の低いドメイン」と同じように、イシューを磨き込んでいると「これは対応しなくて良いものでは?」となることは意外にあると思います。対応しないという判断を伝えると「サボりじゃないの?」と思われてしまうことがあるので、そこはそうじゃないということを共有していかないといけないですよね。

 

Day 2  

ノートの充電を忘れてピンチだったが、空き時間にラウンジで充電できたので事なきを得ました🙏🏻

 前日伺ったらあんまり残ってなくて「明日の朝来てもらえればあると思います!」とのことだったので早々にゲットしました:)

 

 ソフトウェア開発の「今ココ」に適応するために― カイゼン・ジャーニーから見つかった新たなfunと前進への旅路 ―

カイゼン・ジャーニーから見つかった新たなfunと前進への旅路 - Speaker Deck

我々に越境できない境界は無い。

 技術書大賞でもプレゼンされていたカイゼン・ジャーニーについてのセッション。情熱が伝わってくる内容でした。

フレームワーク主導NG」はその通りですよね。まずは悩みや課題に注目して、それを解決する手段としてフレームワークが存在する。

 コミュニティが「野戦病院」というのはなるほどそのとおりだなと思いました。傷を癒す場所ではあるけど、居場所ではない。戻る場所がある。「組織を超えた学びの場」確かに必要だと実感しています。

 買いました:) 付箋も貼らせてもらいました:)

 

Site Reliability Engineering at Google

タイトル通りGoogleさんのSREについてのセッション。

SREは業務時間の50%以上を開発やシステム安定化に関わる業務にあてるというルールがあり、それを脅かすようなシステムの運用は開発チームに突き返す権限を持っている。それによって開発チームが安定したシステムを構築する動機付けができて、SREも開発チームが安定したシステムを開発できるように支援する形になる。非常に理にかなった仕組みですよね。

これを回すには「安定している」を共通認識として定義しないといけない。それは「SLOが満たされている」ということ。SLOを満たすために「エラーバジェット」を使う。エラーバジェット=1.0 - SLO。エラーバジェットを超える=安定していない。

エラーバジェットを超えそうになったら新機能のリリースをフリーズしてシステムの安定化に注力する。それで納期が守れなくなったりするならば、それはSLOの設定がおかしいということ。SLOが100%ということは1回でもエラーが発生するとエラーバジェットを超えるということであり、そのような設定はおかしい。SLOの設定は非常に難しいので、運用しながら調整していくもの。

デベロッパーの「Burnout(燃え尽き症候群)」を防ぐことが大事。つまらない仕事をさせていると燃え尽きてしまう。それを防ぐための50%ルール。「Toil(労力のかかる作業)」を削減することが大事、Toilは悪。

障害対応が終わった瞬間に「Postmortem」を書く。発生要因、対応時の反省点、改善策などを文書化する。記憶のダンプ。個人を非難するような内容を絶対に書かないこと、それは個人のミスを誘発するシステムを設計したチームの責任。言い訳のための文書ではなく、知見の蓄積である。

知見に溢れたセッションでした…。

 

 まとめ

今年は例年に増して共感できるセッションが多かったような気がします。

もらったものを糧にして頑張っていきたい所存ですね…。

 ラウンジで糖分不足にうめいていたら飴ちゃんもらいました:) ありがたし。

#yapcjapan YAPC::Tokyo 2019に行ってきた感想

yapcjapan.org

Twitterで開催するのを知って、「YAPCなら行かねば」とその場でチケットをポチったので行ってきました。場所が浅草橋ということで、旧職場に近くて懐かしかった…。

 建物は外から何度も見ていたけど、入ったのは初めて。

f:id:NYamairi:20190128115005j:plain

ワイヤレスチャージャー

ノベルティがトートバッグ、Tシャツ、ワイヤレスチャージャーと素敵揃いでした:)

(「明日こそやります」缶バッジが見透かされてる感があって良い感じ。)

 

チームが前に進み続けるために僕たちが考えたこと / YAPC::Tokyo 2019 - Speaker Deck @__papix__

プロジェクトを進めるために何をどう変えてその理由はなんなのか、丁寧に書かれていて参考になりました。

"業務・開発フローは「変えることは無条件に正しい」くらいに思って良いと思っています。" @songmu

これは本当に勇気をもらえる素敵な言葉ですね。銀の弾丸が存在しない以上、常に良いやり方を模索していくのが大事なんだろうと思います。

今いる現場で何をどう変えれば良い方向に行けるのか、引き続き考えていくモチベーションがもらえました。

 

私とOSS活動とPerl @duck8823

聴いていてとても良い話だなと感じました。

自然にPerl(プログラミング)に出会って、自分で課題を解決するためにモジュールを書いて、コードを(自宅と職場で)共有したいからGithubに上げて、モチベーションを見つけてCPAN Authorになって、フィードバックをもらってモチベーションが上がって、それによって新しいスキルが身について、勉強会につながってそれが転職のきっかけになって、採用の決め手として自分がやってきた事が評価される。

すごく素敵なことだと思います。そしてそれを共有してくれてとてもありがたい。

 

 

Perl to Go - Speaker Deck @xaicron

Goは A Tour of Go をやった程度しか触っていないのですが、ちょっとPerlっぽいなと思った覚えがあります。(mapを触ってて思ったのかな?)

Perlはガッツンガッツン連想配列を使ってネストするイメージですが、Goはstructを使ってちゃんと型を意識していけるのでより素敵かもですね。(Perlの気楽さも嫌いではないです。)

識別子名の頭文字が大文字か小文字かでpublicとprivateを区別するのが面白いなーと思ってます。名前だけで一目見ればわかるのは良いですよね。

あとはinterfaceの実装を明示的に行わないのも面白いですよね。interfaceと同じシグネチャのメソッドを全部実装していれば実装している扱いになるというもの。Rubyを初めて触ったときに出てきたダックタイピングを思い出しました。

 

 ランチ

 行こうと思ってたつけ麺屋さんは移転してました:(

卓上にリンゴ酢が置いてあって、麺にかけると素敵な風味になるのです:)

 代わりに別のラーメン屋さんへ行きました:)

こちらはおじいちゃんおばあちゃんが夫婦でやっているお店で、チャーシューが1cmぐらいの厚さのブロックで美味いんです:)

浅草橋には他にもじゃじゃ麺とかトンカツとかで美味しいお店があるので、また機会があれば行きたいですね〜。

  

2つのDXと技術的負債-YAPC Tokyo 2019 - Speaker Deck @hiroki_daichi

エンジニアリング組織論への招待 の著者。すごくためになるお話でした。

  • 不確実なものから人は闘争・防御・回避しようとする
  • 人間が本質的にわからない(不確実な)ものは未来と他人
  • 未来には実験による仮説検証で対応する
  • 他人にはコミュニケーションで対応する
  • コミュニケーションは他人が知っていて自分が知らないもの及びその逆のギャップを埋めるもの
  • ソフトウェアづくりはコミュニケーションそのもの(プログラミングは機械が理解できるほど明晰な言語化)
  • 悪い組織構造は悪いシステムを生み出す
  • エンジニアと非エンジニアではシステムに対して見えている情報量にギャップがある
  • 組織をリファクタリングすることでそのギャップを埋める

説得力しかなくて大変わかりやすかったです。

 

YAPC::Tokyo 2019 Log Friendly DB Design - Speaker Deck @fist0

変更履歴をとっておく必要があるデータ(口座残高など)を保持するためにどのようなDB設計が良いのかというお話でした。

今も保守してる私がDB設計したシステムも変更履歴を持っているのですが、1履歴ごとに有効範囲をカラムで持つようにしちゃって取り出しに苦労しているので他の設計が良かったんだろうな〜と後悔してます…。

 

 YAPCはキャリアがPerlで始まったということと、自分から初めて参加したカンファレンスということで思い入れがあります。Perlのコミュニティが持つゆるい空気も好きなので、また参加したいですね:)

#builderscon 2018 2日目

 

nyamairi.hatenablog.jp

 

昨日ちょっと満たされた部分が尻上がり的に満たされていってだいぶ元気になった。やっぱり自分から環境を変えていかないとですな。

「早めに着いたら謎ガジェットをいじって遊ぼうかな〜」などと考えていたが、案の定モーニングを食べる時間が確保できたぐらいだった。(PCを開いている辺りに痕跡が見える。結局この日は謎ガジェットを触る余裕は無かった…。)

あとやっぱりブログはその日のうちに書かないと勢いがなくなりますね、はい。

全てのエンジニアに知ってもらいたいOSの中身について - builderscon tokyo 2018

わりとざっくりした認識で使ってる自覚があるので。

クラウドとかDockerとか出てきてあんまりOSを意識しなくなったよね?最後にOSのインストールをしたのはいつ?」というような導入だったと思います。確かに。

CPUの歴史とかは結構楽しかったけれども、途中からは結構わからない単語が頻出したりしてついていけなくなってしまった…。前提知識的にもっと優しいところから入らないと私には厳しいかもしれない。

あなたの知らないデータベースのロギングの世界 - builderscon tokyo 2018

お仕事でガッツリ使っている割には意識できていない。

実際に運用で使っているお話かと思いきやまだ試してる途中的な内容だった。なので未完。

DB自身でログを吐くとI/Oの負荷が辛いのでProxySQLでやっている。キャッシュとかルーティングとかFirewallとかの機能があるらしい。しかしドキュメントが整備されていないとか、ProxySQL自身でアカウント情報を持っていてバックエンドのそれとズレるとダメとか、charsetがクライアント/ProxySQL/バックエンドの3層で考慮が必要になるとか、ProxySQL自体も大分辛そうである。

そういえばあんまり関係ないけど、前社(10年以上前?)では書き込みはPostgreSQLで読み込みはMySQLという構成のプロジェクトがあって、PostgreSQLの書き込みクエリをMySQLに流すようなことやってて色々辛い部分があったなーと思い出した。(なぜそういう構成だったかと言うと、「PostgreSQLの読み込みパフォーマンスがイマイチ。PostgreSQLトランザクション性能は欲しいけど読み込みのパフォーマンスはMySQLが欲しい。」のような理由だったように思う。当時はペーペーだったのであまり突っ込んで議論できるような感じではなかった。) 

ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ - builderscon tokyo 2018

ピタゴラスイッチ好きです。

Let's Encryptのおかげで大量の独自ドメインに対してHTTPS化することができたとのこと。LE素敵。

万単位の証明書を全部読み込むとメモリと起動時間がエライことになるのでリクエストの度に証明書を読み込むようにしているとのこと。すげえなそんなこと考えたこともない。ngx_mrubyで証明書の読み込み時に動的に証明書を読みにいくという単純な話らしい。nginxさんってそんなことできるのね…。

ピタゴラスイッチは発行の方だった。メモ書きがめっさ多くて全部大事なことっぽい…。

要は「1つの処理(Lambda)でやることを単純にしてワークフロー(StepFunctions)でつなぐ」というのが大事ということだと思う。処理単位を1ドメインにして単純にする。複数ドメインを同時に扱うと「1つ失敗してほかは成功したけど、これって処理全体としては成功なの?失敗なの?」となってモニョる。

1つの処理を単純にした方が良いのはわかるけど、それをつなぐワークフローを構築するのが面倒なのでつい色んなことを1つの処理でやっちゃうんだと思う。そこを簡単にするためにStepFunctionsとかを使うといいということなんだろうな。なのでそういうものがあると知っているのは大事なんだろう。

証明書を保存しているDynamoDBのTTL Triggerで証明書の更新フローを起動するのはなるほどなーと思った。

Using Chrome Developer Tools to hack your way into concerts - builderscon tokyo 2018

デベロッパーツールは上っ面でしか使ってないので。懲りもせず英語を聴こうとする(しかも同時通訳のレシーバを借り忘れた)。

内容としては「動画が再生された回数のカウントをハックされないようにするには〜」という感じ?Chromeデベロッパーツールを使ってハックしてみて、そこからハックを防ぐ方法を考えるみたいな?

XHRのリプレイ機能とかリクエストを出したコードにジャンプするとか、恥ずかしながら知らなかった…便利そう…。

RDB THE Right Way ~壮大なるRDBリファクタリング物語~ - builderscon tokyo 2018

なんかRDBの話って好き。そーだいさんだし。さすがのベストスピーカー。

論理設計と物理設計の違い。ERDの立ち位置。モデリングとは。データと情報の違い。自分の認識と全然違ってめっさありがたかった。そうか…ERDって論理設計で使うものだったのか…物理設計だと思ってた…。

Entityの話。イベントとリソース。この辺りは以前別のところでも聴いたことがあるのだが、結局はっきりとはわかっていない。イベントは事実で過去。リソースはそれ以外。何度も唱えたり資料を読んだりして理解したい。

RDBMSの機能は奥の手」これはわかりやすい。奥の手をいきなり披露するのは悪手ですよね。「今日正しい設計が来年正しいとは限らない」いつの間にかインデックスは貼らないとまともに動かなくなったりね。

このセッションも大事なことがいっぱいあって書ききれない。最後の方は指数関数的にエモくなって終わった(素敵)。

Lightning Talks - builderscon tokyo 2018

色々面白かったけれど、Next Editor に圧倒されてしまった。パない。こういうゴリゴリな感じは憧れる。

Closing - builderscon tokyo 2018

今年も楽しかった。サポーターチケットにしてよかった(謎ガジェットもらえたし)。

改めて自分から環境を変えていかないとなと感じた。環境を変えるのはしんどいけど、楽しくない環境もしんどいので頑張っていきたい。

#builderscon 2018 1日目

久しぶりのカンファレンス参加なのでヘロヘロになるかと思いきや、意外に大丈夫だった。最近は誰かとエンジニア的な会話をすることが少ないので、一方的に聞くだけではあるけどその辺りが満たされてちょっと元気になった。

1日目は「知らなかった、を聞く」のテーマ通りのセッションをわりとうまく選べて満足感。

 

産業でガチ利用されるRaspberry Piの話 - builderscon tokyo 2018

サポーターが貰える謎ガジェットに触発されて。ラズパイは以前から気にはなっていたので、具体的な話が聞けて良かった。

Linuxベースでsshとaptが使えるんだからどうとでもなる」なるほどそらそうだ。これだけで敷居の低さがはっきりわかりますな。安定供給されていて品質が高く汎用性もあれば、そりゃ標準になりますよね。

SDカードはちゃんとしたやつを使わないとトラブるかもとのこと。(T社のものがオススメらしい)

パスワードレスなユーザー認証時代を迎えるためにサービス開発者がしなければならないこと - builderscon tokyo 2018

この辺りは会社でちょっと話題になったのもあったので。個人的にも認証周りは追いかけたい感がある。

パスワードは特定のデバイスが不要でハックされない最強()のメソッドだよね。推測が困難な文字列をサービス毎に考えて覚えて利用するサービスがそれを受け入れてくれればバッチリ。…大体のユーザはそれを満たせるスペックを持っていないよねという話。サービス側も謎の制限とかあったりするしね(長さ制限とか、特定記号縛りとか)。

パスワードを保存するサービス側のリスクとコストも大きいよね。怖い怖い。

そのうちパスワードレスもくるはずなので今から意識して準備しておこう。やり方をいろいろ考えるとどうせ標準と同じようなものになるからはじめから標準に則っておこう。

Webサービスにて200週連続で新機能をリリースする舞台裏 - builderscon tokyo 2018

継続的なデプロイとかリリースとか、そういう世界は一応知っているけど全然できていないので…。

Mackerelの200週連続リリースの話。「リリース」がバグフィックスとかじゃなくてフィーチャ(?)なのが凄いと思います(小並感)。

はじめは特に意識していなくて、50回目のリリースが近づいてきた辺りで気づいたとのこと。つーかその段階ですでに別世界の話感があるのだが。

バックログに対してエンジニアの稼働率を100%にするのは駄目、肌感覚で20〜30%ぐらいの余力が必要。ですよねぇ、遊びがないスケジュールは本当に怖い。余力の部分でリファクタリングとかするのが良いとのこと。

(全然関係ないけどAurora PostgreSQLが既に公開されていたことをMeckerelのリリース履歴で知った。使ってみたい。)

実録!ある担当者がみた「謎ガジェット」開発1年史 - builderscon tokyo 2018

謎ガジェット。ひたすら楽しい話だった。

自分でも触っていくつもりである。

JavaCardの世界 - builderscon tokyo 2018

実は別セッションを聴くつもりだったのだが、移動したときには既に満席だったので。思いがけず面白い話だった。

SIMカードとかはこれが動いているらしい。floatとかcharとかなくてうかつにインスタンス変数を使うとカード自体が壊れるとか、それJavaって名前が付いてるけどCより辛くない?

リクエスト側でレスポンスのサイズを指定するという謎プロトコルでお話するらしい。なんつーかすげー色物ですな。

触ってみたくなったとしても趣味の範疇ではカードに書き込むための鍵をもらえない。エミュレータは存在するがオープンなものはない。なんつーかなんつーかなんつーかですな。

しかし面白かった。

lld − 開発ツールの主要コンポーネントの1つをスクラッチから作成した話 - builderscon tokyo 2018

実は消去法で選んだ感。しかも結構疲れてきてて前半はあまり聴いていなかった。正直自慢話のようにも感じたので…。

しかしよく考えれば実績的に自慢できて当然のことを普通に話しているだけなのだった。なんつーか良くないぞ自分。

速いプログラムはコードじゃなくてデータ構造が速く扱えるようになっている。データ構造が先、コードが後。良いデータ構造ができれば各コードは自ずと決まってくる。

これは感銘を受けました。これが聞けただけでも参加した意味はあると思いましたね。

 

nyamairi.hatenablog.jp

 

#builderscon 2017 を楽しんできました

#builderscon 2017

builderscon.io

YAPCからの流れ(?)で開催されているカンファレンスということもあるのか、個人的には一番リラックスできるというか楽しめるカンファレンスな気がしています:)

知らないことが色々聴けて、大きなモチベーションをもらったように思います:)

 

前夜祭は当日ゴタゴタしていたのもあって参加しませんでしたが、金土の2日間で参加してきました:)

着席したらめっさエモいラップが流れてましたね…

www.youtube.com

富士通クラウドテクノロジーズさんのCMと両極端でしたね^^;

www.youtube.com

各セッションについて感想を書いていこうと思います。

Desktop Apps with JavaScript

builderscon.io

Slack の中の人による JavaScript でデスクトップアプリなお話。

英語のセッションなので同時通訳をレシーバで聴きながら英語も聞き取れるようにがんばろうなどと思っていましたが、同時通訳を聴きながら英語を聞き取るのは難しかったですね…^^;

内容としては Electron を用いたデスクトップアプリの作り方でした。

Electron | Build cross platform desktop apps with JavaScript, HTML, and CSS.

前半に軽くスライドで概要について触れて、あとは実際にコードを読んだり書いたりしながらだったので非常にわかりやすいセッションでした:)

メインのプロセスと描画プロセスに別れていて、描画プロセス内では Chromium と NodeJS の両方が使えるという解釈でよかったのかな?めっさ便利そうですよね:)

前々から Electron は気になっていたので、コレを気に触りたいですね:)

ランチ1日目

www.instagram.com

回転寿司にしました:)

隣が旅行中(?)と思われる外国人三人組で、職人さんの写真を撮ったりしながら寿司を楽しんでましたね:)

トラブル

合間にリモートデスクトップで仕事をしながらの参加だったのですが、リモートデスクトップの調子が悪くなってその解消に手間取っていたため午後イチのセッションは殆ど聴けなかったです:(

接続先のマシンでも画面の描画をするモードで繋いでいたのですが、接続先と手元の両方に描画するのが結構キツイ処理だったらしく、手元だけに描画する設定に変更したら安定しました:)

はじめはリモートか手元の回線が良くないのかと思いましたが、会場の回線は終始安定していたと思います。素晴らしいですね:)

Haskellを使おう

builderscon.io

speakerdeck.com

Haskell は凄いH本を半分ぐらい読んで止まっているレベルなので、また触ってみる機会になればいいなと思って聴きに行きました:)

初めはなんとかついていけたのですが、途中からは正直殆どわかりませんでしたね^^;

現状の私の知識ではなかなかつらい言語だという認識になりました:(

なんでも適材適所なのだろうと思いますが、私が適材を判断できる段階にないということなんでしょうね…

すごいHaskellたのしく学ぼう!

すごいHaskellたのしく学ぼう!

 

 RDBアンチパターン リファクタリング

builderscon.io

個人的にTwitterで何度か(何度も?)お世話になっているそーだいさんのセッション:)

@t_wada さんのSQLアンチパターンもそうですが、わりとRDBの設計に関する話題は興味があるので是非にと聴きに行きました:)

詳細については動画とスライドがあるので触れませんが、データベースがサービスを健康に保つ上で重要であること、嫌な臭いがする設計等についてわかりやすく説明されていてとても良いセッションでした:)

個人的に刺さったのが「リファクタリングをやらない」という選択肢が存在するという点です。リファクタリングするのは好きな方なので、つい費用対効果などを考えずにやってしまう事があるように思います。そこは意識しておかないといけないなと…。

ベストトーク賞おめでとうございます!

LT

それぞれ面白かったですが、印象に残っている2つについて触れます。

builderscon.io

QRコードは16分割できる」

というただそれだけの内容でしたが、非常にシンプルで良い内容でした:)

まさしく「知らなかった、を聞く」でしたね:)

builderscon.io

わりと私の中でもイメージが悪い広告についてのお話でした。

「多重影分身広告(ページをスクロールすると追いかけてきて誤タップ)」

「老眼殺し広告(画面上にデカデカと表示されて閉じるボタンが極端に小さい)」

これらの広告はユーザの印象が悪いし結果として広告主の印象も悪くなって良いことがない。自浄作用で駆逐していきたいという内容だったと思います。

広告自体は悪いものじゃなく、お互いに利益のある関係を築けるといいですね:)

知られざる世界 〜WEB以外のPHP

builderscon.io

(朝マックしてたら少し遅れました^^;)

例によってPHPの世界:)

PHPに対する愛にあふれていて素晴らしいと思います:)とても楽しく聴けました:)

…個人的には仕事でPHPは触らない方向で行こうと思っていますが…^^;

サーバサイドKotlinのすすめ

builderscon.io

サーバサイドのAPIPHPからJavaに移行していたら、ある時小規模なエンドポイントにKotlinで置き換えるPRが来ていて、そのまま取り込んだという話が印象的でした:)

それぐらい気軽に言語を混ぜられるというのは良い環境なのだろうなと感じました:)

構文を見ていて非常にとっつきやすそうな言語だという印象でした:)

ランチ2日目

www.instagram.com

わりと食欲がなかったので麦せいろ(冷麦)でツルッといきました:)

polyglot になろう !!

builderscon.io

複数言語を使えるように鳴ることで、各言語のイディオムを取り入れて良いコードを書けるようになろうという内容だったと思います。

NVIとか、知らなかったのでためになりましたね:)

WEB+DB PRESS 100号記念 特別企画

builderscon.io

実は自分で買って読んだことはないです^^;

技術トレンドの流れが見渡せて面白かったですね:)

Serverless Server Side Swift

builderscon.io

サーバサイドで Swift をやるという興味深いお話でした。

Hexaville という AWS Lambda 上で Swift を動かすために必要な処理を一括でやってくれるエンジンを開発されたということで、必要になったものを自分で作って実用されているというのは、とても素晴らしいなと思いますね:)

GitHub - noppoMan/Hexaville: The modern serverless web application engine and framework for Swift

急遽話す順番が入れ替わっても臨機応変に対応されてました:)

ここが辛いよサーバーレス。だが私は乗り越えた

builderscon.io

結局AWSも他のクラウドサービスも障害は発生する。それを踏まえた上でどこまで備えるか決める。提供されているクラウドサービスも、黒魔術ではなく既存の技術の組み合わせでしかなく、究極的には自分で提供することも可能。

という、当たり前ですが見過ごしがちなことについて改めて示していただけました:)

順番が入れ替わってしまったことについて、終わった後に平謝りされてましたね…^^;

まとめ

全体としてとても楽しい時間でした:)

今はほぼ一人で仕事をしているので、知らない世界の話を聴くのはすごく大事だなと考えています。一人でいるとどうしても知っている範囲のことしか見聞きしなかったり、新しいものに触れたりしなくなってしまうので…:(

これを機に、また新しかったり知らなかったりする事柄をキャッチできるようにアンテナを張りたいですね:)

#devsumi 2016 に行ってきました

今年もデブサミに行ってきました

event.shoeisha.jp

ここ数年は毎年行っているのですが、やっぱりデブサミは良いですね。

なんというかモチベーションが上がります。参加者には開発者からデザイナーから経営者から色々な方がいるんだと思います。それぞれが色々なものを良くしようと思ったり、仲間を募ったり、はたまた単に趣味の話をしにきたりして一つの場所に集まっているのだなと思うとなんとなく気分がアガります:)

Day 1

speakerdeck.com

いきなり素敵なお話でした:)

要件定義とか仕様書出したりとかしてる段階ではお客さんはおとなしくて、動くものが出てきてから色々な話が出始めるというあるある話。

動くものを見ないとわからないことが多いのは当たり前の話で、お客さんから(悪い意味ではなく)クレームが出てくるのは当たり前だと。それを意識しておかないと、お互いに嫌な気持ちになってしまうわけですね。

クレームが出てから直されるまでの間が開くと「諦め」が発生する。これは改善の機会を逸することになるので、短い間隔で継続的にリリースできることが大事。コツコツ継続的にやっていこう。

失敗を0にすることは出来ない。リスクを0にしようとするのは不可能をなそうとしている、リスクをマネジメントしなければいけない。

大事なことは「価値がある」「使える」「作れる」こと。それぞれを判断できる人は別であることが多いので、一緒に考えなければいけない。みんなで集まって解決していこう。

なるべく小さなアウトプットで、なるべく大きなインパクトを出そう!

スクラムとユーザーストーリーマッピングでうまくいくかも?

友情→努力→勝利!!!

ユーザーストーリーマッピング

ユーザーストーリーマッピング

 

 

2つ目は1つ目と内容がもろかぶりだったので、本を立ち読みしてから休憩と充電を兼ねてカフェに行ってきました^^;

f:id:NYamairi:20160224121058j:plain

バナナ美味しかったです:)

 

www.slideshare.net

 打って変わって言語のお話。

JavaScriptも大分こなれてきたという話(だと勝手に理解)。2015年にガツンとバージョンアップされて、しばらくは緩やかな変更にとどまるらしい。他の言語からもいろいろ取り入れているとのこと(C#からAsync Awaitとか)。

JavaScriptにありがちな「でもその機能はこのブラウザで実装されてないよね」問題。トランスパイラ(BABEL)で解決する。最新の言語仕様で書いて、実際にデプロイするときは環境にあった形に変換する。LESSだのSASSだのminifyだのと同じタイミングでやる。

2015でめんどくさかったこととか色々良くなるらしい。文字列内で変数展開できる(バッククォート括り)とか、デフォルト引数とか、可変長引数とか、オブジェクトの特定のプロパティのみ抜き出して変数に代入とか、classとか、ブロックスコープの導入( (function() {...})() ←これを書かなくていい)とか、定数とか、矢印関数(thisが差し替わらない)とか、非同期処理にasync awaitが使えるようになるとか、Setとか、とにかくいい感じとのこと。

パフォーマンスも順調に最適化が進んでいるとのこと。生JSを書くのが苦痛でなくなっているのか、仕事で使ってみたい。

 

www.slideshare.net

こちらはアーキテクチャの話。トレンド(?)になっている「リアクティブ」とか「マイクロ・サービス」とかですね。プロジェクトの進め方系の話と並んで興味のある分野です。

 個人的にはカタカナが多めでそこが結構厳しかったのですが、無理して翻訳しないというのは大事ですよね、うん。

 スライドがしっかりバッチリしていて内容については読めばわかるのですが、まとめるとこんな感じだと捉えました。

  • 分散分散言うけどちゃんと考えて気をつけてやれよ
  • ネットワークとかそんなに信用できないからエラーのケアしろよ
  • サーバとか増えて運用辛くなるからしっかり自動化とかしとけよ
  • 自分たちで頑張るんじゃなくて先人に頼れよ

 

www.shoeisha.co.jp

1日目最後はこちら。毎年これを選んでます:) 

インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門

インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門

 

↑ おすすめポイントはインフラに関して散らばっていた知識が繋がることだそうです:)

個人的には結構興味深い内容だったのですが、いかんせんクラウドイケイケの世相から不利でしたね:(

ハッカーの学校

ハッカーの学校

 

↑ 業界外の人にITについて興味を持ってもらうのが意図だ的なことだったと思います(うろ覚え^^;)。

個人的にはとても喜ばしいという印象で、技術書部門はこの本に投票しました:)

会社に買ってもらう候補です。

プログラマ脳を鍛える数学パズル シンプルで高速なコードが書けるようになる70問

プログラマ脳を鍛える数学パズル シンプルで高速なコードが書けるようになる70問

 

↑ 技術書部門大賞ですね:)

個人で購入したのですが、「サイン本ラス1です^^」と言われてTwitterに投げたら同じことを呟いている方がいて、どっちが真のラス1なのだろうか…

HARD THINGS

HARD THINGS

 

↑  ベン・ホロウィッツさんが実際に直面した困難と教訓をまとめた本とのことです:)

人→製品→利益 の順番で大切にしろとのこと。読んでいると胸が痛くなるとのこと^^;

ビジネス書部門はこの本に投票しました:)

会社に買ってもらう候補です。

ワーク・ルールズ!―君の生き方とリーダーシップを変える

ワーク・ルールズ!―君の生き方とリーダーシップを変える

 

↑ 去年も似た本が出てましたが、所謂Googleの働き方というやつですね。

帯には「グーグル」と入っていますが、別にGoogle独自じゃなくてGoogleだって他から取り入れたりしている、「あのGoogleが!」的な先入観を抱いてほしくないと言っていた気がする。 

↑ ビジネス書部門大賞ですね:)

ディープラーニングの入り口的な立ち位置だとか?個人的に購入したいと思ってます:)

電子書籍版が紙媒体の売上を上回っている稀有な本とのこと。

Day 2

event.shoeisha.jp

(資料が見つからなかった…;)

大体の問題はプログラミングではなくマネジメントの問題。これはまさしくそのとおりだなと思います。

大規模開発をマネジメントし切る実力を持っているマネージャなんてそんじょそこらにはいないのではないか。しかし壁を超えた先には魅力的な世界が広がっている。

アジャイルに期待しすぎるのはダメ。ウォーターフォールはダメだからアジャイルでやりましょうよ的な言葉は鵜呑みにしてはいけない。

問題は方法論ではないのではないか、その場合はウォーターフォールアジャイルだ言ってても解決できない。アジャイルが言っているのは当たり前のこと。乱暴に考えるとウォーターフォールでも細かくやればアジャイルではないか的な(私個人の捉え方です、マサカリが飛んできそう;)。

アジャイル=無計画 ではない(当たり前ですな)。

ツールに振り回されてはダメ。ツールありきで仕事の進め方を決めているのでは本末転倒、やり方が先にあってそのためにツールが有る。

常に反省すること。結局は最初から最後まで「覚悟」と「人」の話である。

 

event.shoeisha.jp

会場を間違えました…(そしてそれに気づいたのは結構経ってから…^^;)

わりとGithub エンタープライズの宣伝的な感じでした。

まとめとしてはこういうパラダイムシフトの導入にあたって費用対効果を出すのは無理なので、熱意で頑張れとのこと。もう流行りとかじゃないんだよ、普及してるんだよ、使えるのがメリットなんじゃなくて使えないことがデメリットなんだよ。

 

www.slideshare.net

はじめはAWSの宣伝かな?と思いましたが、思ったより得るものが多かったです。わりとこれからやろうとしているところにハマりそうな内容でした:)

マイクロ・サービスはクラウドとの相性が良い。小さな部品を組み合わせる的なね。

モノリシックなシステムから開放されよう(「モノシリック」だと思ってた…^^;)。

ここでも分散システムの難しさについて釘を刺される。

API GatewayとLambdaの組み合わせでEC2を使わずに構築するのがイケてる気がする。API GatewayもLambdaも面倒なことを色々やってくれて大変よろしい。ビジネスの本質と関係ないコードの量を減らせる。大抵の場合はEC2よりコストが減る。もちろん必要であればEC2を使ったって構わない。

 

event.shoeisha.jp

(資料が見つからなかった…)

途中からで立ち見だったのでろくにメモも取っていないです…^^;

しかし良い話でした:)

マネージャになって辛いことがあったが、自分のモチベーションを考えなおしてみると意外に合っている仕事だと思い直したとか:)

 

www.slideshare.net

最後は気になっていたブロックチェーンについて。ブロックチェーンの有用性についての話かとおもいきやDisの立場からのお話でした^^;

やっぱり難しくて曖昧な解釈しか出来てません…><

ブロックチェーンは「新聞」の代わり。群衆が「(出来事の証拠としての)新聞」を発行していくようなイメージ(?)。

ブロック(塊)・チェーン(連鎖)

ブロックは取引(TX)の集まり。取引(TX)は状態の変化の記述(例: 送金)。状態の変化の塊の連鎖。

3つの層があり、コンセンサスのプロトコル、ダイジェスト(ハッシュ値)を格納するブロックの連鎖、デジタル署名によるデータ構造となる。

コンセンサスのプロトコルとしては現実と同期して動く上では問題がある。ダイジェストを格納するブロックの連鎖の構造は想定されていたほど強固ではない。デジタル署名によるデータ構造は有益である。

整合性の担保を確率に頼っている部分があるので、コンセンサスの成立とするには弱い(という私の理解)。

Proof of Work。作業コストを膨大に、検証を容易にすることでスパムや不正行為を抑止する。例えば「先頭20ビットが0になるダイジェストを生成できる乱数」を作る、作成には時間が掛かるがその乱数が条件を満たすかどうかの検証は一瞬で可能である。

取引の改ざんはデジタル署名によって不可能であるが、取引の削除は可能性がある。POWによって改ざん者vs世界という図式を作り、事実上不可能にするという理屈だが…あくまでも事実上であって、改ざん者がタイミングを見計らってコストをつぎ込めばBitcoinが破綻する可能性は存在した(する)といえる。

世界各地の主要金融機関がブロックチェーンの研究・実験をしているらしい。

小さいブロックチェーンは小さいコストで破綻させることが可能である。そもそも小さいなら従来の手法でコンセンサスをとればいい。

分散システムは一貫性・可用性・分断耐性の全ては満たせない。ブロックチェーンは一貫性を確保できていない。例として「ビットコインを支払うと上空のドローンがドリンクを落としてくれるサービス」を考える。ドリンクはいつ落とせばいい?ビットコインの取引は確定するタイミングを予測できない。同時に2つのブロックが成立することがあり、そのうちどちらのブロックが有効であるかは時間が経たないと確定しない仕組みである。そのため現実に当てはめるにはリスク(取引が後で無効になる可能性)をとらなければならない。

ブロックチェーンは不確実性というリスクをとれるのであれば有用であり、可能性がある。しかしそうでないシステムには向いていない。

だがしかし、ブロックチェーンが示した世界には魅力がある。

 

 まとめ

やっぱりデブサミはその場にいるだけでも得るものがあるのではないかと思います:)

社長とか忙しいので行けないとの事だったが、ぜひとも優先順位を上げていただきたい。

モチベーションを頂いたので、得たものを活かして楽しくやっていきたいです:)

他に気になったお話

失敗から学ぶデータ分析グループのチームマネジメント変遷 (デブサミ2016) #devsumi

エンジニアコミュニティで組織は動き出す

【資料公開】強いチームの作り方(デブサミ2016版) | Ryuzee.com

外注が主な企業でどのように内製開発を立ち上げ・進化させているのか?

今日の習慣が明日をつくる~よりよい技術者を目指して~ - Google スライド

プロダクト開発におけるプロダクトマネージャーの役割とは #devsumi‬