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
chat-hatenablogをpip installでインストール可能にした - $shibayu36->blog;
https://github.com/shibayu36/chat-hatenablog/releases/tag/v0.3.0 chat-hatenablog v0.3.0にてchat-hatenablogをpip installできるようにした。以下のようにすれば、GitHubから直接コマンドをインストールできる。 pip install git+https://github.com/shibayu36/chat-hatenablog.git この結果、current directoryをベースとして、index.pickleや.envを置くことはできなくなったため、配置場所を変えた。 ~/.chat-hatenablog/index.pickle ~/.chat-hatenablog/.env 今回の変更で、git cloneしてそのディレクトリで実行するといった面倒なことをする必要
継続的に学習するために効いたやり方3つ - $shibayu36->blog;
育児していて時間があまり取れない状況下で継続的に学習するために色々な方法を取り入れているんだけど、その中で最近めちゃくちゃ効いた3つのやり方を紹介。 やりたいことリストを作っておく 今日のTODOリストを作る 2分間コーディング やりたいことリストを作っておく 自分が学習したいことの一覧があると、優先度を決めやすくなり、またやりたいことが1つ終わった後すぐに次に取り組むこともできる。そこで僕はTrelloでリストを作り、とにかく少しでもやってみたいと思った開発や、読みたいと思った本などがあれば追加している。 今日のTODOリストを作る 時間が空いてから「今日はこれから何をやろうかな？」と考えていると、途端にやる気がなくなってダラダラしてしまう。そこで先に今日のTODOリストを作っておくということをやっておく。ポイントとしては 細かい家事やプライベートでやること、勉強すること全て含めて同じリ
読書のやり方を変えてみたら知識の吸収速度・引き出し速度が上がった話 - $shibayu36->blog;
最近以下のような記事や本を読み読書法を変えてみたところ、知識の吸収速度・引き出し速度が上がったと感じるので紹介。 kentarokuribayashi.com 知的戦闘力を高める 独学の技法 作者:山口周ダイヤモンド社Amazon やり方 以下のような流れで読書している。 学びたいと思った知識が書いてありそうな本を2~5冊選ぶ 1冊ずつざっくり読みながら、面白かった部分・気になった部分はKindleで黄色にハイライトしておく 全冊読み終わったら、ハイライトした部分だけ眺めて、やっぱり面白いと思ったところは赤のハイライトを付け直す 赤のハイライトを眺めて、読書ノートに転記する 特に面白い部分については、自分の知見まとめノートにカテゴリごとに整理する 学びたいと思った知識が書いてありそうな本を2~5冊選ぶ 自分の中で学びたいテーマがあって本を読むはずなので、そのテーマについて書いてありそうな本
良い物件ではなく良い不動産屋を探した - $shibayu36->blog;
いろいろあって今の家から引っ越すことになった。 良い物件どうやって探したらいいか分からなかったので、適当にググって http://nanapi.jp/286/ を実践してみたら、結果的にうまく行ったので経験をメモ。 結論 良い物件を探すのではなく、良い不動産屋を探すという方法にしたところ、僕の性格としては上手く行った 今回の流れ suumoやhomesで住みたい場所の物件を眺める 希望条件をまとめる 不動産屋を選んでメールしまくる 良さげなところを数社に絞って、さらに送られた物件見ながら返信してみる 一番いい感じに返答してくれた雰囲気の店に行って相談 suumoやhomesで住みたい場所の物件を眺める http://nanapi.jp/286/ とやってることは一緒なので割愛 希望条件をまとめる http://nanapi.jp/286/ とやってることは一緒なので割愛 不動産屋を選んでメ
つかまらない上司にならないために - 1分間マネジャーの時間管理を読んだ - $shibayu36->blog;
1分間マネジャーの時間管理 パンローリング株式会社Amazon 「1分間マネジャーの時間管理」を読んだ。非常に面白く、勉強になることが多かった。 この本は、マネジャーが時間に追われている状況をどう解決するかについて教えてくれる。この本においてプロジェクトにおける「次の対応」はサルと表現され、マネジャーが時間を作るためにはこのサルの管理をうまくしなければならないというような話で、時間に追われている状況の改善方法について説明している。書き方自体も時間に追われたマネジャーを主人公として物語風に進んでいくので、非常に読みやすく面白かった。 上に書いた通りの話なので、マネジャーになってなぜか忙しくなったと思う人は是非読んでみると良さそう。確かにそれで忙しくなってるわーみたいなことがいろいろ書かれているので参考になると思う。 この本の中でメインとなるポイントは オンケン流サル管理の心得 三つの時間をや
いつ突然会社をやめても問題ないという基準でコードやドキュメントを書く - $shibayu36->blog;
先に前提を話しておくと、会社は全く辞めるつもりはないし、むしろどんどん会社を良くしていこうと思っている。今回はそういう基準で自分がコードやドキュメントを書いていますよという話。 コードやドキュメントを書く時に、どのくらいきれいにしておくかとか、どのくらいわかりやすくしておくかとかを考えることがある。こんなとき僕は、いつ突然自分が会社をやめて連絡がつかなくなったとしても他の人がある程度理解できるか、を基準にしている。そのためにはあまりいい方法が思いつかなくて仕方なく書いている部分にはちゃんと経緯のコメントを書く。他にも例えば作ったサービスであるイベントを開催する方法のドキュメントを書くなら、全く何もやったことがない人がそのドキュメントを読んだらとりあえず開催できるよう、ドキュメントを書く。当然コードもかっこよさよりも、説明しなくても分かりやすくなるようなシンプルさを追求する。 また、このよう
評価制度の目的とは何か考えてみる - $shibayu36->blog;
最近どのような人事評価制度が良いものなのか考えている。どういうシステムが良いかを考えるためには、まずは人事評価制度はどういう目的で行われるのかを考える必要があると思い、まずは人事評価制度は何なのかについて自分なりに考えてみたいと思う。 今のところいくつかの本を読んで、自分の意見をまとめているという段階なので、中身の正確さは保証できない。間違っているところなどあれば指摘してもらえると。 人事評価制度の目的は何か 「そうか、君は課長になったのか。」「マネジメントとは何か」「1分間マネジャーシリーズ」など、いくつかの書籍を読んだ所、人事評価制度はマネジメントという文脈で非常に重要なポジションであることが見てとれた。 これらの書籍を見る限り、以下の様なものが人事評価制度の目的となるのではないかと考えている。 報酬による外的モチベーションの管理 社員教育の促進 会社の方向性を社員に伝搬させる 報酬に
マネジャーの仕事のエッセンスが学べる「そうか、君は課長になったのか。」を読んだ - $shibayu36->blog;
マネジメントシリーズとして、「そうか、君は課長になったのか。」を読んだ。 そうか、君は課長になったのか。 (ポケット・シリーズ) 作者:佐々木 常夫WAVE出版Amazon この本は課長になった部下に対して、以前の上司が課長の仕事とは何かについてお手紙を送るという形式で書かれている。非常に平易な文章で180ページくらいの本なのだけれど、マネジャーがやるべき仕事のエッセンスがある程度書かれており、仕事の価値を伝える重要性、目標設定の重要性、コーチングの技術、真摯さの必要性など、マネジャーに必須な概念を勉強することができる。マネジャーを3ヶ月くらい体験すると、この本をあーあるあると思いながら読めるので、その時期に読むのが最適だと感じた。 この本のなかで、印象に残ったのは以下の二点。今回はこれについて書こうと思う。 現状を把握するために、真っ先にすべての部下と面談する 評価は指導のためのもの 現
先に疑問を考えてから本を読む - $shibayu36->blog;
久々に昔のエントリを読み返していたら、以下の様な記事があった。 最近の本の読み方 - $shibayu36->blog; どんな本を読むかの部分と、読んだ後ブログに書くというのはずっと変えてないが、最近は読む時どうするかという部分についてちょっと調整を加えている。この部分について書いてみる。 ちなみに今回説明する本の読み方は、特定の事柄を学習したい場合に読む本に限定している。ざっくり興味関心で読む本はここまでしっかり読まず適当に流し読みしてる。 読むときの流れ 読むときは以下の様な流れで読む。 目次を見ながら学びたいことを疑問形式で書く 読みながら印象に残った部分をメモ書きする 最初に書いた疑問に答える 読書ノートテンプレ(自作)に従ってまとめる ブログに書く ここから以前会議の前に決めることは何か - 「感動の会議！」読んだ - $shibayu36->blog;で書いた「感動の会議」を
目標と発達度によってリーダーシップを使い分ける - 「1分間リーダーシップ」読んだ - $shibayu36->blog;
チームでの自分の振る舞いを考えるために、1分間マネジメントシリーズの「1分間リーダーシップ」を読んだ。 1分間リーダーシップ―能力とヤル気に即した4つの実践指導法 作者:K.ブランチャードダイヤモンド社Amazon この本ではいくつかの種類のリーダーシップを状況によって使い分けると良いということについてフォーカスし、リーダーシップの使い方について言及されている。マネジャーになった時にリーダーシップは必要な技術なので参考になる。 この本で言いたいことは、その人の目標を決め、その人の目標に対する現在の発達度から、リーダーシップのスタイルを使い分けるべきである、ということ。それを言うためにその前提としていろいろなことを教えてくれている。マネジャーになった人なら参考になると思う。 目標と発達度によってリーダーシップを使い分けるというのが、これまでなかった観点だったので面白かったので、今回はそれにつ
「シバソン」という名の何も準備しないイベント - $shibayu36->blog;
最近、シバソンという名のほぼ身内でやっているイベントを開催している。シバソンとはシバハッカソンの略で、なぜか適当にハッカソンしますと会社で呼びかけたら自然とシバソンという名前になっていた。今日は勉強会について簡単に書きたいと思う。 Kyoto.pm 以前自分はKyoto.pmというperl界隈のイベントの主催をしていた。このイベントは最初もっといろいろな人にアウトプットする場を提供したいという気持ちで始めたイベントだった。有名な東京のperl hackerを呼べたり、東京からはるばる来てくれる人が何人かいて、けっこう面白いイベントに出来たと思ってる。 ただ問題点がいくつかあった。 一つ目は主催者が開催のために前準備(スピーカー集めとか)をするコストが非常に高かったこと。発表会形式にすると、特に関西ということもあって、全然スピーカーが集まらないということがよくあった。そのたびにいろんな人に声
レビュータイムの導入・消滅・再導入 - $shibayu36->blog;
今日こんなかんじの会話があって、レビュータイム導入した時のことを思い出したので、適当に書こうと思う。 ひさいちレビュー、必ず通すみたいなの良いのか悪いのか— ひさいち (@hisaichi5518) 2014年3月13日 @hisaichi5518 マジレスすると、そのような体制にしておくとスケールしないので、最初の段階では必ず通すというルールにしつつ、他の人がレビューしても大丈夫に出来るように、レビューの練習を同時にしていってもらうとしないといけなさそう— 柴崎優季 (@shiba_yu36) 2014年3月13日 @hisaichi5518 今のチームで新人が入った時は、レビュータイムというのを必ず設けてその時間には最低限どれか一つレビューするというのをやってもらってる。でも慣れるまではこれまでチームにいる人がレビューしないとmergeしないということにしてる。— 柴崎優季 (@shi
開発のドキュメントをどこに置くか問題 - $shibayu36->blog;
最近開発用のドキュメントをどこに配置するか悩んでて、いくつか試して見てる。今回言っている開発用のドキュメントというのは、コードの触り方も含んだサービスの開発に関するもの。例えば 開発環境セットアップ方法 ページに表示している広告をどのように切り替えたりするか(googleの管理やコードの変更も含めた) サービス内の特定の機能の仕組み 内部用HTTP APIドキュメント などを指している。 結構いろいろ考えるところがあるので、思っていることをまとめてみたい。一応先に結論を言っておくと 基本は実装に一番近いところにコメントとしてドキュメント書くのが良いと思う いろんなパーツが絡みあうような大きな機能の場合、導入部分だけ別の場所に書く 出来るだけrepository内に入れておくと探しやすく、更新しやすいと思う あといろいろ悩んでるので事例あったら教えてください。 起きている問題 ドキュメントは
コードレビューを円滑に行いたい (#cross2014 のお話) - $shibayu36->blog;
id:antipopさんやid:studio3104さんに機会をもらえて、CROSS 2021に参加させてもらい、はてなでのレビューの話を軽くさせてもらった。はてなからは僕とid:hakobe932さんとで参加した。 http://blog.kentarok.org/entry/2014/01/18/204552 2014/1/17 #cross2014 コードレビューCROSS 〜ぶつかり稽古 2014初場所〜 - Togetter それで、今回参加して他の会社の人のレビューの話も聞いて、あーそれはあるあるとか、そういう問題解決するためにこういうことしてますとか、他の会社ではこういう時どうしているんだろとか、幾つかおもうところがあったので、もう少しレビューのことについて書いてみる。 レビューと関係性問題 レビュアーとレビュイーの関係に関して - 職質アンチパターン コードレビューと関係性
ペアプロの成功体験と失敗体験 - $shibayu36->blog;
ペアプロって難しい。今のところ、基本的にうまくいかないことが多い。 その中でもたまに成功体験みたいなのがあったので、それを書いてみる。今回の話はあくまでも主観で感じたことである。断定的な書き方をしているのは単に書きやすいからであって、他意はない。あと失敗体験も書いておく。 今回の話に初心者と上級者という言葉が出てくる。これはペアプロ対象に対する初心者・上級者というものとする。なので初心者は「ペアプロ対象に対してあまり知識を持っていない」人であり、上級者は「ペアプロ対象に対して知識をある程度持っている」人とする。 ペアプロ対象の定義は難しくて、Perlで書かれたものであれば、Perlの知識は必要だけど、Perlで作られたある機能の知識や、もしかしたらMySQLの知識みたいなものも対象になりうるかもしれない。そのようなものを漠然とまとめて、ペアプロ対象と言っておく。 成功体験 ペアプロ対象に対
Server::Starterから学ぶhot deployの仕組み - $shibayu36->blog;
以前http://tech.naver.jp/blog/?p=1369の記事を読んだのだけれど、それまでにprocessの知識が無かったりして、まったく理解できませんでした。そこでWorking with UNIX ProcessesやServer::Starterの中身を呼んでようやくhot deployの仕組みを理解できた(気になっている)ので、Server::Starterの実装を追いながら、それをまとめてみます。 hot deployとは hot deployとは「再起動の時にリクエストの処理を続けながら、変更の内容を反映するための手段」です。 通常serverをrestartさせるときは、stop -> startの流れになると思いますが、この場合stopしてから、start出来るまでの期間にリクエストを処理できない期間が発生します。その期間なしにdeployする仕組みがhot
Web Applicationを綺麗に設計するためのMVACという考え方 - $shibayu36->blog;
【2016/03/04追記】以前まとめたこのMVACという名前の設計は既に古くなっており、今はこのようなアーキテクチャで設計していません。 こんにちは。最近ははてなでMVACというアーキテクチャに則って開発をしているのですが、ようやく意味を理解できてきました。そこで今回は「Web Applicationを綺麗に設計するためのMVACという考え方」について、サンプルを交えながら説明していこうと思います。かなり長くなってしまったので、時間があるときにでもどうぞ。 MVACって？ データソースやロジックを扱う「Model」、表示・出力を管理する「View」、複数のModelとControllerをつなぐApplication、ユーザのリクエストなどを受け取りViewやApplicationを制御する「Controller」の4つの要素を組み合わせてシステムを実装する方式。MVCをさらに抽象化した
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
