ひょうたん

年末年始に 「一分で話せ」 を読みました。内容はプレゼンや報告などで基本になる型の説明とともに、以下のようなビジネスコミュニケーションにおける基本的な考え方やコツについての解説になっています。 コミュニケーションのゴールは人を動かすこと 人を動かすためのコミュニケーションのコツ コミュニケーションの主導権を自分自身が握っておくことの大事さ、など 自分自身の考え方と近しい箇所が多く、改めて言語化するのによい本だったなと感じます。 有用、かつよくまとまっていて読みやすい本なので、新人やコミュニケーションの熟練度の低いメンバーにとりあえず入門として読んでもらうのにもよさそうな一冊でした。 「結局、動かしてなんぼ」 「1分で話せ」の主張の中心としてはこれに尽きます。コミュニケーションの型としてのピラミッド・ストラクチャーを中心に1分で話せという内容が書かれていますが、ビジネスにおけるコミュニケーションは相手に動いてもらうことが目的になります。 そこの考え方の軸さえしっかりしていれば、あとはどのように相手に動いてもらうか、どうしたら相手が動いてくれるかという課題に落とし込む作業になります。あとは知識と経験を積むことによってそこのスキルは伸ばしていくことができます。 全体を通して自分の中で暗黙的になっていた考え方との合致も多く、言語化の役に立つなと感じました。他の方にもオススメできる一冊です。

先日Prisma Postgresのearly accessが発表されました。Prismaからの利用に制限されますが、従量課金制のPostgreSQLサーバーレスDBとして利用することができるようです。個人開発で固定費用なしでRDBを使うことができるのはとても嬉しいですね。 ですがpsqlでの接続ができないので、pg_dumpの出力をpsqlで取り込むお決まりの手順が使えず、既存のデータをインポートするのにはちょっと手間が必要です。 この記事を書いている2024/11/02時点ではデータのインポート、エクスポート手段は公式に用意されてはいないようでした（まだearly accessですしね） 以下のdiscussion内容を参考にpg_dumpで元DBからdumpを出力し、改変しつつ生SQLとして読ませるseedスクリプトを用意することでインポートに成功しました。 無事成功！ 以下は移行にあたっての記録です。 Prisma Posgresの登録 https://www.prisma.io/postgres からログインして登録していく。クレジットカードの登録は不要。 webからぽちぽち登録していけば用意ができる 東京リージョンが用意されている...！ Generate database credentialsをクリックすると接続情報が生成される。接続情報は DATABASE_URL="prisma+postgres://accelerate.prisma-data.net/?api_key=xxxx" という形式になっており、独自プロトコル+api_key指定での接続なのでpsqlなど従来のPostgreSQL用のツールは使えない。 念の為psqlでの接続を試してみたけどやはり接続できなかった。 運用中のDBのデータをインポートする 基本はseedか。生クエリを書けるので、pg_dump結果をseedで読ませたらおおよそなんとかなりそうな気がしてきた www.prisma.io/docs/orm/pri... [image or embed] — もひゃ ( @mohya.bsky.social ) 2024年11月2日 16:53 この方針でなんとかなるんじゃないかとあたりをつけて試してみる。 まずはスキーマを元DBから取得して...

先日「スタッフエンジニアの道」を読みました。本書は部下を持たない上級技術職として「スタッフエンジニア」を定義し、どういう役割を求められ、どういうスキルを発揮し、どうあるべきかのひとつの形を示すという内容です。 「成熟した大人」として振る舞い、リーダーとしての成果を上げる 本書では以下の3点をスタッフエンジニアのスキルの三本柱として定義し、3部に渡ってそれぞれを構成するサブスキルに分けて説明していくという構成になっています。 大局的な思考 実行 レベルアップ 全編を通して「スタッフエンジニアはリーダーである」ことが必須であり、リーダーとして成果を出していくために「成熟した大人」としての振る舞いが必要であるという価値観を貫いています。 この背景としてはスタッフエンジニアというのはあくまで、マネージャーとは異なる方法で組織に貢献し、成果を出すリーダーである。ただ与えられた課題を解き、そのためのコードを書き続けた先にリニアにレベルアップした先に待っている役割ではないということが根底にあるのだと思います。 （このあたりの話はEM.FM Re.33 "「技術力」って何？"の後半で話題に出ていて、かなり面白かったのでオススメです。） パッシブな影響力/アクティブな影響力の発揮 「第III部 レベルアップ」でパッシブな影響力とアクティブな影響力という考え方は個人的にハッとさせる部分で面白かったです。（多分ゲームでよくあるパッシブスキル（明示的に使わなくても効果が発揮されるもの）/アクティブスキル（明示的に使うことを選択することで効果が発揮されるもの）を想定しているんじゃないかと思う） パッシブな影響の事例としては例えばその人がどのように責任を持って仕事に取り組んでいるのか、といった「責任ある大人としての姿勢」をとり続けることによって周囲のメンバーやその組織の文化に与えるような例を、アクティブな影響としてはコードレビュアーとして「ガードレール」の役割を果たすことで明示的に影響を与えることができる、というような例を提示しています。 普段、自分自身の行動の影響力を意識することは少ないですが、本書で提示された概念を念頭におきつつ振り返ってみると、新たな意味づけができそうだなという感触があった箇所でした。

先日、 fukabori.fm 62. プロダクト・レッド・オーガニゼーション を聞いて「先行指標と遅行指標」の話に感銘を受けた。 「プロダクト・レッド・オーガニゼーション」の背景にある「プロダクト・レッド・グロース」モデルについて先に知っていると、後日、前者を読んだときにより理解が進むような気がしたので本書を読んだ。 分野的にはプロダクトマネジメント関連の書籍と近いところがあると感じたが、基本的にはビジネス側からの視点なので、プロダクト側からだけではない視点を増やすためにも読んでみてよかったなと思う。 プロダクト・レッド・グロースモデル 本書ではプロダクト・レッド・グロース（以下、PLG）モデルについて紹介・説明している。これは表紙の言葉を借りれば「プロダクトでプロダクトを売る」ビジネスモデルだ。本文中ではプロダクト主導型ビジネスモデルと訳されている。 セールス主導型ビジネスモデルと比較しながら、PLGモデルが適するビジネスの類型や、適用するにあたって重要なポイントなどを紹介している。 この本の中で私がなるほどと思ったポイントのひとつが「ビジネスのインプットとアウトプットを知る」という部分だ。 「第12章 最適化プロセスを開発する」の中で持続的な成長を実現するためのプロセスとして「トリプルAスプリント」というものを紹介している。このプロセスにおいて外すことができないものがビジネスに必要なアウトプット（ARRなど）を生み出すインプット（展示会、広告、eメールマーケティング）が何かを理解することだとしている。 どんなインプットが望むアウトプットを生み出しているか理解していなければ、持続的な成長を実現することはできない。なるほど確かにそうかもしれない。これまでを振り返ってみるとインプットに対する理解があまりない状態でアウトプットについて考えていることが多かったように思う。言うは易く行うは難しかもしれないが押さえておくと役に立つ考え方だと感じた。 余談 少し前にmasuidriveさんのこのツイートがバズっていた。 エンジニアが会社を選ぶときに評価をするのは年収以外に「事業ドメイン」「技術スタック」と共に「理解がありアホなこと言わない上司、経営陣」と「適切な成長機会」があると思う 特にアホに説明する心理コストは高いから、なぜメモリがたくさんいるのかとか、この機能の変更は大...

LOCAL Developer Day Online ’21 /Security に参加してきました。セキュリティの知見を広げるよい機会となりました。主催したLOCAL、せきゅぽろのみなさまありがとうございました。  Developer-First Securityという考え方 LOCAL Developer Day Online ’21 /Security はじまりました〜 Session 1. Developer-First Security という考え方 講師： 米内 貴志 (株式会社Flatt Security 執行役員 CTO) #ldd21sec pic.twitter.com/aJpdm7gsF4 — LOCAL (@local_hokkaido) September 4, 2021 Developer-First Security の背景 設計・開発者が安全にものを作れるとセキュリティってよくなるんじゃない？ セキュリティの範囲は広い 人によって「セキュリティ」が指すものは違う セキュリティに関わる人も多い 設計・開発者が安全にものを作れる環境が大事では？ 安全にものを作れるよいプラクティスはあまりないのではないか うまくいっているセキュリティプロダクトにはDeveloper-Firstという共通点がある これまでのセキュリティプロダクトに課題があった すぐ使えない、コストが高い UXが常人向けではない 開発者の環境になじまない セキュリティプロダクトでうまくいっているスタートアップの共通点としてDeveloper-Firstという考え方があるようだ Developer-First Securityとは 1. 開発者の活動圏にとけこんでいく 開発フローに組み込める製品にすることで開発者のセキュリティへの関心や行動を自然に引き出すようになっている。ツールに密結合したりしている。 ex.) Snyk：GitHubと連携して改善のアクションまでをサポートしている ex.) GitHub：数多くのセキュリティ機能を展開している。 2. 開発者の技術スタックにとけこんでいく 例えば認証処理なんかは要件が複雑になりがち。ここをサービスとして提供することで技術スタックに押し込む。認可のサービス化もあったりする ex.) Auth0 ex.)...

ツイッターの投稿を見る限り1月末くらいからはじめたようだ。 unity、移動制御をPhysicsまかせにするとこんな感じになるのかー。ウケるけどこうではない pic.twitter.com/X6vwC7j0NU — もひゃ (@onjiro_mohyahya) January 25, 2020 2月末くらいの時点でこんな感じ。 よしよし、そこそこゲームっぽい雰囲気が出てきた気がするなー pic.twitter.com/shyKoIn52c — もひゃ (@onjiro_mohyahya) February 29, 2020 元々はSFネタで1本アクションゲームを作ろうかなーと思っていたけど、ネタがあまり煮詰まらないので、とりあえず昔描いたミクのドット絵で適当に作ってみることにしたのだった。 お話はねぎ畑を荒らされたミクがたこルカをしばきに行くみたいな感じになりそう。適当な感じにしておくと気が抜けてよい。 今はボスのたこルカを作っている。ドット絵を打つの面倒すぎなのでたこルカはやめたほうがよかったかもしれない。 たまにgh-pagesも更新。zでジャンプ、xでネギ https://t.co/1Ki8H7lJbY — もひゃ (@onjiro_mohyahya) February 29, 2020 ちなみにシルフェイド幻想譚の作者のsmokingWOLF氏の本で紹介されていた"力尽きたらそこで完成"メソッドで進めているので、力尽きたらそこで終わりにしようかと思っている。

昨年、 本当に取り組む課題を見つける、課題発見ワークショップ in Sapporo  に参加してきました。会社のSlackで紹介されて、なんとなく「面白そうだなぁ」という動機で参加してきたのですが、想像以上に楽しかったの最高でした。 年末あたりに記事にしようと思ってたけど気張りすぎて出力できなくなってしまったので供養。。。 こんなワークショップだったよ ワークショップの目的は次の通りでした。 課題設定の重要性を理解する 課題の見つけ方を体験する 課題解決までのプロセスを体験する 内容としては課題設定の重要性についての話をし、実際にワークをいくつかやってみるというのをいくつかやる、という形式で進みました。 ワークショップの中では課題発見の方法として、以下の考え方やテクニックが紹介されていました。 認知問題、技術問題 問題の分解とリフレーミング スマートとシニカル HMW Framework、我々はどうすれば〇〇できるだろうか、という形式で考えてみる よりよい課題発見の方法にも型がある 課題の見つけ方の体験というのはじめてやった チームでの課題が面白かった。途中でこれは厳しそうだなぁと思ったけど、なんかそれなりになんとかまとまった。ちょっとびっくりしました 背景の異なる人とワークすると刺激がある いっしょにワークを実施したチームメンバーは全然背景の異なる方々で、開始するときにはちょっと心配だなぁと思っていたのですが、逆にこれはこれでよかったかもしれません 次はこれやってみようかな 話の中で紹介されていた本、「他者と働く」が気になったのでどこかで読んでみようかなぁ。。。

「カスタマーサクセス――サブスクリプション時代に求められる「顧客の成功」10の原則」を読みました。 だいたいこんな感じの内容でした。 Salesforceがサブスクリプションこれまで買い切りだったソフトウェアの世界にサブスクリプションを誕生させた。サブスクリプションの世界では導入時の売り上げよりも、契約し続けてくれることによりもたらされる売り上げのほうが大きく、重要になってくる この世界では更新、アップセルが特に重要になってくること。このためにはソフトウェアを導入した顧客が目的を達成できることや、ファンになってもらうこと（＝心理ロイヤリティの創出）が求められること 売り上げ比率の変化により、これまでの社内での力関係に変化が発生している。これまでは契約取得に対して責任を持つセールスが力をもっていたが、更新に対して責任をもつ部署へとバランスが傾いてくるようになった 更新に対する責任の遂行にあたっては何か問題があったら対応するというこれまでのカスタマーサポートよりも、事前に手を打って顧客の心理ロイヤリティを高めるカスタマーサクセスという動きがより重要視されている 今後 CCO（Chief Customer success Officer）が出現し、重要なポジションとなっていくであろうこと サブスクリプションはソフトウェア以外の分野でも今後増えていき、カスタマーサクセスの重要度が多くの分野で増していくであろうこと 「カスタマーサクセス」って実際のところなんなの？ これまでカスタマーサクセスという言葉について、「耳障りのよい言葉で、なんかよさそうなやつだけど、実際に何を指しているのかが、人によって考えていることがバラバラでふわふわしたもの」という認識でした。この本ではもう少し具体的にカスタマーサクセスとはなんぞ？というものが定義されており、「カスタマーサクセス」という言葉が出てきた時に認識を合わせるひとつの指針として利用できそうだなと感じました。 カスタマーサクセスという文言は、ロイヤリティの創出、特に心理ロイヤリティの創出という言葉の言い換えにすぎないということだ。 カスタマーエクスペリエンス大事、、、大事 読んでいてこれは確かにそうだよなぁ、なるほど〜と思ってマーカーを引いていた部分を挙げておきます。 最高のカスタマーエ...

このブログは Blogger で書いています。現時点で使っているテーマではこれを Twitterから リンクした場合、いい感じに画像や概要が表示されてくれていないようでした。 せっかくなのでいい感じに表示されてくれると嬉しいのでちょっと調べてみました。 Twitter Card を設定したぞー！できたはずだ！どうだ？ https://t.co/8aZYCawR1y — もひゃ (@onjiro_mohyahya) October 29, 2019 これを調べる現時点で僕が知っていること、考えていることはこんな感じでした。 Twitterに投稿したときに写真と概要を表示するようにしたい 画像や概要を表示するにはOGPを設定する必要があるはず OGPについて詳しいことはあんまり知らない BloggerでOGPを設定するには多分テーマに何か手を加えるとうまいことできるんじゃなかろうか 調べて色々と試した結果、最終的に以下のようなコードを Blogger テンプレートの head タグに仕込むことで目的を達成することができました。いえーい <!-- OGP --> <meta content='xxxx' property='fb:app_id'/> <meta content='website' property='og:type'/> <meta expr:content='data:view.title' property='og:title'/> <meta expr:content='data:view.url' property='og:url'/> <meta expr:content='data:view.featuredImage' property='og:image'/> <meta expr:content='data:view.description' property='og:description'/> <!-- Twitter Ca...

2シーズン履いたジャックパーセルのかかとの内側の布が破れてきてしまっていたので修理した。壊れたものを分解したり直したりするのはなかなか楽しい。 白い革のジャックパーセル。結構汚れているように見えるが実際結構汚れている。 こんな感じでかかとの内側に貼ってある布が破れてきていた。こうなるとかかとがめっちゃこすれるようになるので、靴下に穴が空いたりかかとが靴擦れになったりして塩梅がよくない。今回はこれを修理していく。 紺色のインソールがはいって。ジャックパーセルにはかなり厚手のインソールがついている。これは僕が持っている登山用の靴のインソールより厚手だったりする。 使うのは代わりの布とハサミとボンド。この写真では2種類布を用意してあるけど最終的は奥にある濃い紺色の布だけを使った。ボンドは手芸店で売っていた皮革とか布とかゴムとかをつけることができるやつ。先日はシャンプードレッサーのプラスチック棚を直すのにも使ったりした。ほとんど万能、とても便利。 ちなみに今回は手元にあるものを使って直したけど、道具がない場合はAmazonとかで売っている修理キットをそちらを使った方が簡単だと思う。ネットの噂によるとちょっと高めになるけど靴の修理屋さんとかでも直してもらえるらしい。 破れてベロッとなっていた部分の布を切り落とす。破れていた部分以外は接着剤か何かでくっついているようで簡単には剥がせなかった。 インソールを外した方が作業がしやすいので、作業時は外している。 破れた部分に貼る布を適当に切って合わせてみる。端の部分はほつれてくると嫌なので折り返してボンドで止めた。 布は手元に持っていた紺色のものを使った。質感からなにがしかのジーンズ生地のきれっぱしだと思われる。元は白い布が貼ってある場所なので白いガーゼ布みたいのでももちろん問題ないし、柄物の生地とかでも面白いかもしれない。 サイズもよさそうだったのでボンドで貼り付けていく。中心の線を最初に留めてそこから左右を留めていくとやりやすかった。底の面のあたりはどうせインソールで隠れるので綺麗に切りそろえたりはしなかった。 インソールを入れたところ。インソールの厚みがあるので、下の方はほとんど隠れている。まあまあよさそうだ。今回使った布がインソールとかなり色の近い紺なのであまり違和感はないと思...

妻のリクエストでかぼちゃのタルトを作りました。うまー👍 実際に作ったのは中身の具・・・？の部分だけでタルトの台は富澤商店で買ってきました。かぼちゃを煮て潰して混ぜて焼くだけなのでめっちゃ簡単。 かぼちゃのタルト！🎃 at 自宅 https://t.co/FXWA9AcgVB #miil — もひゃ (@onjiro_mohyahya) October 22, 2019 レシピは これ タルト台は 富澤商店で買ってきたやつ そのまま上にフルーツとか盛り付けて フルーツタルトとか作れるみたい すごー もうちょっと甘さ控えめでもよかったな。また作ることがあれば少し砂糖減らす 実家にタルト型があったような気がするのでまだあればもらってこようかな 気が向いたら次はりんごパイに挑戦したいなぁ・・・

Developers.IO 2019 in Sapporo というイベントに参加してきました。 これはクラスメソッド株式会社が開催するイベントで、クラスメソッドさんのエンジニアが主に技術系の話題を話すイベントです。札幌での開催は実に2年ぶりとのことでした。登壇者の記事、資料は こちら でいくつか公開されています。 基本的には技術系の話が多く、AWSに強いクラスメソッドさんらしくAWSサービスに関連した話題が多かったです。 僕は普段業務でAWSを使ってはいるものの、使ったことがあるサービスはそんなに多くはありません。名前は知っているけど中身はよく知らないというサービスについて話を聞きながらググって「あー、なるほどこれってこういうやつだったのかー」となるよい機会になりました。 AWSのサービス、めちゃくちゃ大量にあるけど、自分で使ったことあるのって一部だけなので、聞いたことはあるけどなんだかよく知らないサービスが話の中でたくさん出てくる。聞いてるだけで、あー、あれってこういうやつだったのかーっていうのがわかるなぁ #cmdevio — もひゃ (@onjiro_mohyahya) October 19, 2019 どれも面白い話だったのですが、今回の話の中でちょっと異色だった最後のお二人、じょんすみすさんとすもけさんの話が特に印象深かったので紹介します。 じょんすみすさんのデータ分析の話が熱かった 本日の「全部Excelだけで実現しようとして後悔するデータ分析」の発表資料です #cmdevio https://t.co/H9qjeLx9ef — じょんすみす (@__john_smith__) October 19, 2019 タイトルは「全部Excelだけで実現しようとして後悔するデータ分析」でした。もうタイトルからして地獄のような感じです。 怒涛のExcelでできる分析講義を受けている。なにもわからない・・・ #cmdevio — もひゃ (@onjiro_mohyahya) October 19, 2019 データ分析のプロであるじょんすみすさんの頭の中をドバッとぶちまけたような怒涛のセッションでした。内容はExcelへの愛と憎悪（？）、Excelで行うデータ分析入門？、 Alteryx ならそれも簡単にでき...

note に書いたよ。 4ヶ月くらいモブワークしてみたけど、なかなかいいよ、っていう話

人間の思考の枠組みのひとつである「物語」「ストーリー」とは何か？というのを考える本。 特に目的もなく、なんとなく読んでみたわりにはとてもよかった。 この本ではストーリーを「できごと」と「その前後関係」という捉え方をする人間の思考の枠組みであるとして紹介している。 人間はストーリーによって多くの恩恵を受けている一方、ストーリーに捕らわれてしまうことで苦しい思いをすることもある。ストーリーという思考の枠組みについて知り、自覚することで、それにより苦しめられる危険を減らせるかもしれないですよ、というのが主な内容だった。 最近一緒のチームで仕事をしている @niku_name が以前、「人間の認知にはバグがあり、よく認知の偏りが生まれる」と言っていた。もしかするとその原因のひとつにこの本で扱っているストーリーという思考の枠組みがあるのかもしれない。 以下にこの本の中で僕が特に気になった話を記載しておく。いつか気合が出てきたらこれらの話が関係する参考文献を読んでみるかもしれない。 責任とは、どうやら、問いに答えることらしい オーストラリアの脳外科医で精神科医のヴィクトル・ E・フランクルが「死と愛　実存分析入門」および「人間とは何か　実存的精神療法」で責任という概念を重視している、という話で出てきた言葉。 責任（Antwortung, responsibility, responsabilité）とは、どうやら、問いに答える（antworten, answer, respond, répondre）ことらしいのです。 この一節は「人生への期待を手放す」という章の中で出てくる。自分が人生に期待することをやめ、自分を待っている何かや誰かへの責任を自覚し覚悟することで、期待とセットである絶望を乗り越え、耐えていくことができるようになるという話だった。 これが気になったのは実はこの話での主張とはあまり関係がない。以前「責任」とはなんだろうということについて考えていたことがあり、その時にはそれに対する納得できる回答を思いつくことができなかった。それ以来、責任とはなんだろうなーということが気になっていた。 僕にとって「責任とは問いに答えること」というこの考え方はある程度納得感のある主張であるように感じられた。これに...

最近趣味のアプリで Phoenix 1.3 を 1.4 に上げたら ueberauth_github の認証時に Poison.decode!/1 is undefined というエラーになるようになってしまって困った。 最終的にわかったこととしては現時点ではまだ周辺ライブラリが Poison 依存の状態になってしまっているようなので、諦めて Poison も入れておくことにした。状況が変わったらそのうち追記する。 mix.exs defp deps do [{:phoenix, "~> 1.4.0"}, ... {:jason, "~> 1.0"}, + {:poison, "~> 3.1.0"}, ] end Phoenix の JSON パーサーのデフォルトは Jason になった 1.4 にバージョンアップするときに phoenix の json パーサーとして 1.4 からのデフォルトである Jason を使うように指定し、Poison を依存から外した。 1.3 から 1.4 へのバージョンアップ手順はこちらを利用した。 https://gist.github.com/chrismccord/bb1f8b136f5a9e4abc0bfc07b832257e 2019/01/19現在の ueberauth まわりの対応状況 ueberauth の master には対応する pull request がマージされているもののまだこれは publish されていない。対応の pull request はこれ。 https://github.com/ueberauth/ueberauth/pull/88 ueberauth 本体は対応したもののの、oauth2 などが対応できていないため、ueberauth_github や ueberauth_google はどうやらまだ Poison なしには動かない状況のようだった。 https://github.com/ueberauth/ueberauth_github/issues/43 https://g...

先週 PostgreSQL勉強会札幌 に参加してきました。最高でした。 石田さんの話相変わらず濃すぎるwww 「ポスグレが8kbのブロックにアクセスする様子をnodejsに食わせてsocket.ioで可視化してみました」 #jpugezo — Tomoki MAEDA (@tmaeda) 2017年2月25日 プランナの機嫌をさぐりながら進むデモ #jpugezo — S.Yachi (@syachi) 2017年2月25日 お品書きはこんな感じ 喜田さん（@kkkida_twtr）の発表。去年の12月にリリースされた PostgreSQL9.6 関連の話 石田さん（@iakio）の発表。PostgreSQLが アクセスしたページ(8kbのデータブロック単位のこと)位置をブラウザでグラフィカルに表示する仕組みを作ったので、色々と遊んでみる PostgreSQL9.6 の話については、パラレルクエリが入ったぞー、とか FDW が進化したぞーとか断片的に情報を知っていたのですが、まとめて色々と聞けたり、パラレルクエリの実際のところの話が聞けるのはありがたい限り。 あとはPostgreSQL10 の話も少しあって、パーティションテーブルへの insert が遅い問題（9.6以前は trigger で実行する・・・）の改善が入ってくるというのがいま一番気になるところ。。。 石田さんの発表については、ディープながらも個人的にはかなり興味深いところでした。ReadBuffer 関数に printf() を仕込むことでページのディスクアクセスとキャッシュからの読み込みを出力し、Node + Socket.io でグラフィカル表示するというものだったのですが、こう、、、普段頭の中でイメージしているものとの答え合わせをするような感じで見ていました。 SeqScan とか Index Scan とか NL Join とかを見つつ、あーそうそう、そうですよねー、そうなるはずですよー！とか、追記型なので UPDATE でもディスク使用領域増えていきますよねーとか。VACUUM が走ったのでディスク領域再利用されるぜやっほう！とかそんな感じです。超楽しいw 実際にデモしてもらった内容はだいたい頭の中と合致するなぁという感じだ...

プログラミングElixirの第13章、GitHubにアクセスしてIssue一覧を取得するというのを写経していたら表題の問題にはまりました。https のサイトに接続しようとすると発生するようです。 こちら に従って hackney のバージョンを 1.6.1 に下げることで回避できることを確認したのでご報告します。かしこ { :httpoison, "~> 0.8" } http://api.github.com/repos/elixir-lang/elixir にGetリクエストを投げる 301 Moved Permanently を食らう https://api.github.com/repos/elixir-lang/elixir にGetリクエストを投げ直す おおっと handshake failure！！

この記事は PostgreSQL Advent Calendar 2016 の8日目の記事です。 PostgreSQL では配列型がサポートされており、多次元配列を扱うことができます。 データ集計などを行う際に配列型を利用することで多少難しいロジックの実現や速度の向上といった恩恵を得ることができる場合があります。 ところがマニュアルの 配列関数と演算子 の項目を眺めてみるとお気づきになると思うのですが、多次元配列を1次元配列に一発で展開するような関数は用意されていません。 以前、ARRAY_FLATTEN が欲しいなぁと思って調べてみたのですが、現時点では何らかの方法で自前で実現してやるしかないようです。 今回、次の3種類の方法を検討しパフォーマンスについて調査してみました。他には自前で集約関数を実装するという方法もあると思いますが、今回は標準の機能で実現できる方法に絞っています。 UNNEST & ARRAY_AGG ARRAY_TO_STRING & STRING_TO_ARRAY LATERAL & UNNEST & ARRAY_AGG 結果としてはどうやら3の方法が、そこそこ安定した速度が出て、気をつける点も少ないため扱いやすそうでした。 追記：あとで気づいたけどスカラサブクエリでも良かった。

今年の2月に翔泳社のキャンペーンで買い、積ん読にしていた 「 プログラマ のためのDocker教科書 インフラの基礎知識＆コードによる環境構築の 自動化 」 を読みました。 僕は用意された環境で `docker-machine create` と `docker-compose --build -d up` しか使わない程度の初心者で、正直これまでは「Docker 面倒だなぁ」という感想だったのですが、これまでちゃんとわかっていなかった次のような点が理解できた結果「お、Docker意外と面白いのでは」という気持ちになってきました。わかるって楽しい。 `docker ssh` するとどこにつながっている？ Dockerfile と docker-compose.yml って同じような指定がない？ docker-compose build すると何が作成される？ 手元で作ったコンテナを別環境に持って行って動かせるんだよね？ 内容はインフラの話から、dockerの構成要素の話、dockerコマンドの話、Dockerfile、Docker Hub、Compose、Machine、SwarmからAmazon ECSまでと現時点で Docker を利用するにあたって必須となる知識 + αくらいまでをうまく網羅して解説してくれているので、僕のように中途半端にDockerを使っているという人から、今まで使っていないけど新しく知りたいという人まで幅広くお勧めできる感じの本でした。 とはいえ、これを読んだ翌日とてもよくわかった気持ちで Docker コンテナをいじろうとしたらいろいろと詰まるところがあったので、ちゃんと手を動かして覚えるのも大事ですね。。。

2016/11/11 に開催された Developers Festa Sapporo 2016 に午後から参加してきました。以下のセッションを見てきました。 アプリ／サービスをもっと魅力的にする！Twilioを使ったコミュニケーション機能 基礎からわかるDevOps System of Record と System of Engagement 最後にあった登壇者全員によるふりかえりセッションなどを聞いていると、特に naoya さんの話のインパクトが大きかったなぁという気がします。 「SIを下げてWebを上げるのはもうやめませんか？」 この方向のお話を伊藤直也さんから聞けたのは大きい。 #devfesta — オム子( °⊿°) (@irasally) 2016年11月11日