タグ

ブックマーク / blog.shibayu36.org (9)

  • CLIツールを作るとき、ユーザー設定ファイルやデータをどこに配置するか - $shibayu36->blog;

    chat-hatenablogをpip installでインストール可能にした - $shibayu36->blog;にてchat-hatenablogをpip installできるようにするとき、ユーザー設定ファイルやデータをどこに配置するかに迷った。このツールでは、環境変数の設定として.envファイルを、ブログデータのインデックスとしてindex.pickleファイルを使っている。 これらのファイルの置き場所について少しだけ調べたので、現状分かったことをメモしておく。 まず選択肢としては二つありそうだった。 ~/.chat-hatenablog/.envと~/.chat-hatenablog/index.pickle 例) ~/.asdf、~/.docker、~/.gemなど XDG Base Directoryの仕様に沿って、~/.config/chat-hatenablog/.en

    CLIツールを作るとき、ユーザー設定ファイルやデータをどこに配置するか - $shibayu36->blog;
    rAdio
    rAdio 2023/05/01
  • 「エンジニアメンター制度の効果的な運用を目指して」という発表をEngineering Manager Meetup #5でしました - $shibayu36->blog;

    エンジニアメンター制度の効果的な運用を目指して」という発表をEngineering Manager Meetup #5でしました Engineering Manager Meetup #5で「エンジニアメンター制度の効果的な運用を目指して」という発表をしてきました。 自分も久々の発表で緊張しましたが、自分の頭をまとめる良い機会になりました。他の発表も学びが多く、とにかく濃いミートアップでした。このような機会を与えてくれた運営の方に感謝です。また機会があったら参加・発表したいです! 以下は発表内容のまとめです。 発表内容 アジェンダ はてなのチーム横断のエンジニアメンター制度とは 実際にどのような課題があったか どのように改善したか 改善施策により最終的にどうなったか 今回の施策を通しての気付き: マネージャ向けにも当たり前のことをする イントロ 自分がマネージャっぽい仕事をしていると以下

    「エンジニアメンター制度の効果的な運用を目指して」という発表をEngineering Manager Meetup #5でしました - $shibayu36->blog;
    rAdio
    rAdio 2019/04/18
  • 問題意識を感じたときに「効率的に良い状況に変える」ためのアクションリスト - $shibayu36->blog;

    自分の置かれた環境で問題意識を感じることってありますよね。例えば 上司全然ちゃんとやってくれないじゃん!最悪! 会社にこういう問題あるじゃん!なんで直らないの!最悪! みたいな感じ。 昔はこういう問題意識を持った時、自分で「良い状況に変える」ことに苦労をしていました。しかし、最近は自分の意識を変えることで「効率的に良い状況に変える」ことをしやすくなったなと感じています。そこで今回は、どのように自分が意識を変えたかということと、問題意識を感じた時に最近試しているアクションについて書いてみようと思います。 昔に自分がよくやっていたアクション 問題意識を感じた時、昔に自分がよくやってしまっていたのは 飲み会の場で愚痴る 上司に詰め寄る 問題意識だけを提起する というようなアクションです。このようなアクションをした時、良い上司はちゃんと話を聞いてくれて、実際に問題が解決することも多くありました。

    問題意識を感じたときに「効率的に良い状況に変える」ためのアクションリスト - $shibayu36->blog;
    rAdio
    rAdio 2019/03/05
    「問題はあるけど、目の前の仕事は片付く気配もないし、余裕もないし、そもそも会社自体大して儲かってるわけでもないし、だからといって良い条件で転職できるわけでもないし。今の生活のためには仕方がないし…。」
  • アプリケーションは全員で監視する - 「入門 監視」を読んだ - $shibayu36->blog;

    最近話題になっていた「入門 監視」を読んだ。アプリケーションの監視をするための実践的なノウハウが詰まっていて非常に参考になる書籍だった。 入門 監視 ―モダンなモニタリングのためのデザインパターン 作者:Mike Julianオライリー・ジャパンAmazon このでは、アプリケーションを監視するための骨格となる考え方や、様々な層(フロントエンドからOSのメトリックまで)での監視の入れ方の実践的なノウハウ、さらには障害対応をスムーズに行うためのフローや障害の根対応をチームで行えるようにするためのやり方まで書かれている。実践的なすぐに取り入れられるような内容が多く、「アプリケーションをどう監視したら良いか分からない!」「障害対応をもっとうまくやる方法はないのだろうか?」と思う人には参考になる部分が多いと思う。 個人的にこのの中で一番良いなと思ったのは、 SREだけでなくアプリケーションエ

    アプリケーションは全員で監視する - 「入門 監視」を読んだ - $shibayu36->blog;
  • 「エンジニアリング組織論への招待」はいろんな立場の人に読んで欲しい - $shibayu36->blog;

    最近メンタリング制度のことや、技術組織のことについて興味がある。最近「エンジニアリング組織論への招待」というが出版されて話題になっていたので読んでみた。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング 作者:広木 大地技術評論社Amazon このは、エンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」ということと述べている。その考え方に従って、思考方法、メンタリング、チーム運営、組織運営といったプログラミング以外でのやるべきことについて、様々な背景も含めて教えてくれる。 全部読んでみたところ当に良いであった。メンタリングや組織運営といった、なかなか汎用化や言語化がしにくい分野を、納得のできる形で言語化されていて当にすごい。僕は最近はメンタリング制度について考えているので、特にChapter2のメンタリングの技術の章が一番

    「エンジニアリング組織論への招待」はいろんな立場の人に読んで欲しい - $shibayu36->blog;
  • ioドメイン障害を理解するため、DNSの仕組みについて勉強した - $shibayu36->blog;

    先日、ioドメインの障害があったのだけど、自分がDNSの仕組みをよく分かっていないせいで、いまいちどういうことが起こっていたのか把握できなかった。そこで、DNSの仕組みについて軽く勉強したので、そのメモを残しておく。内容は間違っているかもしれないので、その場合は指摘してください。 DNSについて学んだこと Software Design 2015/4のDNSの教科書が非常に勉強になった。また、 インターネット10分講座:DNSキャッシュ - JPNICも参考になる。 権威サーバとフルリゾルバ まず、DNSサーバには権威サーバとフルリゾルバの二つの種類が存在する。 権威サーバ ドメインの情報を管理し、自分の管理しているゾーンの情報を提供するだけのサーバ 問い合わせたドメインが自分のゾーンの管理下ではない場合、別の権威サーバへ委任するという情報を返す コンテンツサーバとも言われる? 例) co

    ioドメイン障害を理解するため、DNSの仕組みについて勉強した - $shibayu36->blog;
    rAdio
    rAdio 2017/10/05
    DNSやメールなど、サーバ内だけで完結しないものの管理は苦手だ…。
  • AMPについてのコンテンツ消費者としての感想メモ - $shibayu36->blog;

    昨日、「AMPが導入された結果、現時点ではモバイルのブラウズ体験が大きく損なわれてるのですが、そう感じるのは僕だけでしょうか」とTwitterでつぶやいたら、いろいろ反応があり、いろんな観点を知ることが出来たのでメモしておく。なお、自分自身はまだAMPのコンテンツを実装したわけではなので、開発者の知識はなく、ただのコンテンツ消費者としての知識しかない。開発している人から見るとまた違った見え方があるかもしれない。 コンテンツ消費者側のメリット・デメリットという観点 AMPによるコンテンツ消費者側のメリットは速度面だが、モバイルを利用していた時に現時点では速度に困っていなかったので、自分はメリットを享受できていない 現時点では、いろんな理由によりユーザ体験が損なわれている部分がある ユーザ体験が損なわれている例としては、プラットフォームの問題とコンテンツ制作側の問題の両方がある プラットフォー

    AMPについてのコンテンツ消費者としての感想メモ - $shibayu36->blog;
    rAdio
    rAdio 2016/11/09
  • ペアプロの成功体験と失敗体験 - $shibayu36->blog;

    ペアプロって難しい。今のところ、基的にうまくいかないことが多い。 その中でもたまに成功体験みたいなのがあったので、それを書いてみる。今回の話はあくまでも主観で感じたことである。断定的な書き方をしているのは単に書きやすいからであって、他意はない。あと失敗体験も書いておく。 今回の話に初心者と上級者という言葉が出てくる。これはペアプロ対象に対する初心者・上級者というものとする。なので初心者は「ペアプロ対象に対してあまり知識を持っていない」人であり、上級者は「ペアプロ対象に対して知識をある程度持っている」人とする。 ペアプロ対象の定義は難しくて、Perlで書かれたものであれば、Perlの知識は必要だけど、Perlで作られたある機能の知識や、もしかしたらMySQLの知識みたいなものも対象になりうるかもしれない。そのようなものを漠然とまとめて、ペアプロ対象と言っておく。 成功体験 ペアプロ対象に対

    ペアプロの成功体験と失敗体験 - $shibayu36->blog;
    rAdio
    rAdio 2014/05/26
    『後ろから見られているために、簡単なことでも検索するという行為が恥ずかしく思ってしまう。』『上級者も完全に知っているわけではないので、二人してググるみたいな行為が始まってしまい、グダグダになる』
  • Kansai.pmに行ってCinnamonというデプロイツールについて発表しました - $shibayu36->blog;

    http://www.zusaar.com/event/476003 に参加して来て、前作ったデプロイツールであるCinnamonについて発表して来ました。 発表したこと 以前capistranoの奥深さに毎回ハマっているのを怒りを覚えて、もっとシンプルなデプロイツールであるCinnamonをantipopさんと一緒に作ったのでその発表をしてきました。それなりに好印象っぽかったので、発表してよかったです。 スライド Cinnamon - simple deploy tool from Yuki Shibazaki デモで使ったサンプルコード https://github.com/shibayu36/cinnamon-deploy-sample 簡単に紹介すると CinnamonはMinimumというのと、Role x Taskというのを思想として持っている Minimum : デプロイの方

    Kansai.pmに行ってCinnamonというデプロイツールについて発表しました - $shibayu36->blog;
    rAdio
    rAdio 2013/02/24
    これが一番聞きたかったのに、インフルエンザで行けなかった…。くやしいのぅ。ギギギ。
  • 1