タグ

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

  • git logの内容を検索する-Sと-Gの違い - $shibayu36->blog;

    ずっとgit logの内容を検索するときに-Sオプションを使っていたが、実は近いオプションに-Gオプションもあり、探したい内容によっては使い分けないとダメということを初めて知った... 詳しくはhttps://git-scm.com/docs/git-logの-Sと-Gのドキュメントを見てほしい。簡単にまとめると -Sは指定した文字列の出現回数が変わるdiffがあるcommitを検索する -Gは指定した正規表現がマッチする文字列がdiffにあるcommitを検索する ドキュメントの事例部分が結構わかりやすくて、以下のようなdiffがあった場合 + return frotz(nitfol, two->ptr, 1, 0); ... - hit = frotz(nitfol, mf2.ptr, 1, 0); -S frotzで検索をかけると、frontsの出現回数は変わってないのでマッチしない

    git logの内容を検索する-Sと-Gの違い - $shibayu36->blog;
    kiririmode
    kiririmode 2023/09/26
    -Sも-Gもdiffに対する検索で、前者は検索対象の出現数変化、後者は正規表現マッチにヒットする
  • 開発パフォーマンス指標とバリューストリームマップでチーム改善をする - $shibayu36->blog;

    以前Pull Requestから社内全チームの開発パフォーマンス指標を可視化し、開発チーム改善に活かそう - Hatena Developer Blogの記事で、開発パフォーマンスを可視化する話を書いた。その後、バリューストリームマップを作り開発フローの課題を洗い出して、チームの改善を行い、そして開発パフォーマンス指標で効果を検証する取り組みを行ったので、その経験についてブログに書いておく。 前回の記事のサマリー バリューストリームマップを作り、開発フローの課題を発見する バリューストリームマップとは何か チームのバリューストリームマップを作る バリューストリームマップから課題を見つける 見つかった課題を解決する 開発パフォーマンスの指標で改善結果を振り返る まとめ:データを根拠にチーム改善するという進歩 参考 前回の記事のサマリー 前回の記事を前提として書くため、簡単にサマリーすると 開

    開発パフォーマンス指標とバリューストリームマップでチーム改善をする - $shibayu36->blog;
    kiririmode
    kiririmode 2021/08/11
    バリューストリームマッピングの実践例。次回devops研修で紹介
  • リモートワークでは自己主張スキルが大事な気がしてきた - $shibayu36->blog;

    リモートワークをしていると特定のスキルを保有しているか否かで自分の成果や成長が大きく変わってくると感じてきている。その中の一つとして最近感じているのが自己主張スキル。 なぜそう感じるか。それは最近ローカルでの開発からリモートの開発になったことで、自分がメンタリング・ファシリテーション・スクラム開発などをしている時に、非言語情報である表情や相槌、目線などの情報を使って良い感じに対処することが非常に難しくなったからだ。リモート会議だとミュートを多用したり人によってはビデオを切っていたりするので*1、言語情報以外の情報が全く入ってこなくなり、「良い感じ対処」のための情報量が圧倒的に不足するようになってしまった。例えば メンターとして困りごと相談を受けている時間に沈黙が生まれると、理解していて沈黙しているのか、今考え中で沈黙しているのか、全く理解不能で沈黙しているか分からず、どう対処したら良いか分

    リモートワークでは自己主張スキルが大事な気がしてきた - $shibayu36->blog;
  • どのようにエンジニアの目標設定を行うか - $shibayu36->blog;

    以前 ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog; で、「ゴールを決め、現在位置とのギャップを考え、目標を決める」と良いということをまとめた。イメージとしては以下の図の通り。 しかし、前回の記事だと具体的にどのようにエンジニアの目標設定を行うかイメージが湧かない。そこで、もう少し具体的に最近どのようにやっていたかを書いてみたいと思う。 僕がメンティーと目標設定を行うときは、以下のフローを辿っている。 なんでも良いのでゴールのイメージを明確にする 現在の自分とゴールのイメージのギャップを考える ギャップを埋める目標を考え、アクションを定める ちなみに今回は、チームの成果達成のために個人の目標を決めるのではなく、エンジニアのスキル向上の目標を立てるという前提で書いていく。 なんでも良いのでゴールのイメージを明確にする

    どのようにエンジニアの目標設定を行うか - $shibayu36->blog;
  • 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

    Server::Starterから学ぶhot deployの仕組み - $shibayu36->blog;
  • 手元開発環境でサーバを起動時のみcronのようにスクリプトを実行する(Perlの場合) - $shibayu36->blog;

    これまでPerlを利用した手元開発環境でどのようにcronを動かすか迷ってきたのだけど、その解決策が見つかったのでメモ。 課題 開発サーバや番サーバではcronで定期的にスクリプトが実行されている 定期的に実行されているスクリプトが動かないと、正しく動かない機能がある 例えば予約投稿みたいな機能など しかし手元開発環境ではcronのように定期的にスクリプトを実行していなかった 結果として、手元開発環境で手動でスクリプトを動かさないと確認できない機能があった 解決策として手元でもcrontabを書く方法もあるのだけど、この場合開発していない時も勝手に実行されるので避けたかった。 解決方法 実はProclet というツールに、サーバを起動しながら定期的に指定したコードを実行してくれる機能があるということに気づいた。詳しくはSYNOPSISを参照。 これを使ってcronに指定しているスクリプト

    手元開発環境でサーバを起動時のみcronのようにスクリプトを実行する(Perlの場合) - $shibayu36->blog;
  • 「HTML5/CSS3モダンコーディング」読んだ - $shibayu36->blog;

    HTML5/CSS3モダンコーディング フロントエンドエンジニアが教える3つの格レイアウト スタンダード・グリッド・シングルページレイアウトの作り方 作者:吉田真麻翔泳社Amazon 最近自分のプロジェクトのデザイナが、JavaScriptで実装しないといけないと思っていたことをどんどんCSSで実装していくのを見かけた。この出来事から、JSで実装したほうが良いか、デザイナにやってもらったほうが良いか、どちらが良いかを自分で判断できてないと感じたので、最近のCSS事情を知りたいと思って読んだ。サラッと流し読みするだけで、CSS3で利用できるようになったよく使うプロパティの概要を把握できたので、今の自分の知りたいことが分かって非常に良かった。 例えば以下のことを学ぶことが出来た。 reset.css, normalize.cssとはなにか beforeやafter擬似要素を使ったいろんな技

    「HTML5/CSS3モダンコーディング」読んだ - $shibayu36->blog;
  • 自分流Elasticsearch入門 - $shibayu36->blog;

    【2016/09/10追記】 勉強しなおして、Elasticsearchの知識についてさらにまとめた記事を書いたので、そちらを参照してもらうと良さそうです。 blog.shibayu36.org 最近Elasticsearchの勉強をした。ただ、入門のためどのような資料が適しているかを知るのが大変だった。そこでどのように勉強したかについてメモをしておく。少しまとめエントリー的なノリになりそう。 Elasticsearchの概念を知る 全文検索技術の基を知る Elasticsearchのドキュメントのたどり方を知る の順に学習を進めていった。 Elasticsearchの概念を知る Elasticsearchの学習を始めようとした時に、まずは基からということで以下のを読んでいた。 高速スケーラブル検索エンジン ElasticSearch Server (アスキー書籍) 作者:Rafal

    自分流Elasticsearch入門 - $shibayu36->blog;
  • serfとDockerでクラスタを組んでみる - $shibayu36->blog;

    最近Serfというツールも気になっていたので、とりあえずクラスタを組んでイベントハンドラの設定をしてみるところまでやってみました。 Serfとは http://www.serfdom.io/ https://github.com/hashicorp/serf Serf is a decentralized solution for service discovery and orchestration that is lightweight, highly available, and fault tolerant. Orchestrationという層を支援する軽いツールみたいですね。これをうまく使うことで、クラスタにjoinしたweb serverを自動的に配下に加えるHAProxyとかを実装したり出来ます。参考: Serf+HAProxyで作るAutomatic Load Balanc

    serfとDockerでクラスタを組んでみる - $shibayu36->blog;
  • CinnamonをMinilla管理にした - $shibayu36->blog;

    Minillaが流行っていたので、僕もCinnamonをMinillaに対応させてみました。 とりあえず $ cpanm Minilla 次にCinnamonのdirectoryにいって、migrate。 $ cd cinnamon $ minil migrate Cannot retrieve 'abstract' from /Users/shibayu36/development/myprojects/perl/cinnamon なんか怒られた。これはDist名とDirectory名が違っているため、migrateができなくなっていた。 directory名を変えてやってみる。 $ cd .. $ mv cinnamon Cinnamon $ cd Cinnamon $ minil migrate とりあえずこれでmigrateは出来た。続いてFAKE_RELEASEしてみる $ FA

    CinnamonをMinilla管理にした - $shibayu36->blog;
  • vagrantでVMを一度に複数台立てる - $shibayu36->blog;

    以前、#kyotopm 04 Hackathonを開催して、Cinnamonの並列化に取り組んでいました - $shibayu36->blog; でも少しだけ触れましたが、vagrantでVMを一度に複数台立てるのをちょっとだけ試したのでメモ。 vagrantはMulti VMに対応していて、設定を少し書けばvagrant upするだけで複数のVMを立てることが出来る。Multi-Machine | Vagrant by HashiCorp あたりが参考になる。 precise32でまっさらなサーバを立てる 例えばpreciese32を使って、まっさらのサーバを2台立ててみる。以下の設定を書いてvagrant upするだけで良い。 Vagrant.configure("2") do |config| config.vm.box = "precise32" config.vm.box_url

    vagrantでVMを一度に複数台立てる - $shibayu36->blog;
  • 「入門Chef Solo」を読んでChefに入門した話 - $shibayu36->blog;

    これまでChefとか全くやったことなかったのだけれど、PrePANとかで必要になったのとなんとなく興味もあったので、naoyaさんが最近出した入門Chef Soloを読んでみました。 入門Chef Solo - Infrastructure as Code 作者:伊藤直也伊藤直也Amazon 読んでみた感想としては非常によくまとまっていて分かりやすいけど、全くChefをやったことない人にとってはChefの実行を試すフェーズが少しやりづらい印象を受けました。理由としてはAWS環境を持っていない場合、2,3章のChefを試す章ができず、さらにそのあとにvagrantでローカルに仮想環境を作るのを学んだとしても、その仮想環境を使って試す部分が少ないためです。 そこで僕は全くchefをやったことない人はまずvagrantでの実行環境を作れるようになってから、を読み始めるとより知識が深まるのではな

    「入門Chef Solo」を読んでChefに入門した話 - $shibayu36->blog;
  • emacsのruby環境を整えています - $shibayu36->blog;

    最近VagrantとかChefとかCapistranoとか、それなりにrubyのプロダクトを触るようになったし、別の言語の良いプロダクトも見ないといけないという気分になったから、とりあえずemacsの環境を整えようと思い出した。まずは基から。 ruby-mode modeはruby-modeを使えばいいっぽい。多分標準で入ってると思う。rubyは.rbつかないような奴も多いので、それは適当にruby-modeに紐づくようにする。中身を見てrubyと判別するやつもあるような気がするけど、まだそれは使ってない。 (autoload 'ruby-mode "ruby-mode" "Mode for editing ruby source files" t) (add-to-list 'auto-mode-alist '("\\.rb$" . ruby-mode)) (add-to-list '

    emacsのruby環境を整えています - $shibayu36->blog;
  • http://shibayu36.hatenablog.com/entry/2012/12/29/001418#mc?u=ainame

    ふとemacsの設定どのくらいになっているのかなーと思って行数数えたら wc -l init.el inits/* | grep total 2303 totalと、とんでもないことになっていたので、これまでどんな設定してたか思い出すことも兼ねて、emacs設定大掃除をおこなってみました。そこで「これは捨てられないなー」と思った設定を淡々と書いていきます。 ちなみに実際の設定ファイルはhttps://github.com/shibayu36/emacs/tree/master/emacs.d を御覧ください。 init-loader.el emacsでinit-loaderを導入してみた - $shibayu36->blog; の記事でも書きましたが、init-loaderは便利です。最近の構成としてはinit.elにはinit-loaderの設定だけ書いて、inits以下に全部設定置いて

    http://shibayu36.hatenablog.com/entry/2012/12/29/001418#mc?u=ainame
  • expand-region.elでperlのコードの範囲選択 - $shibayu36->blog;

    expand-region.elの紹介 - syohex’s diaryで紹介されていたexpand-region.elを使っていたのですが、expand-region.elはmodeごとにいろいろカスタマイズ出来るようでした。しかし、これまでperl用の設定がなく困ってました。 で、色々探してたらhttps://github.com/magnars/expand-region.el/pull/83 というpull requestがあったので、mergeされないかなーと思っていたら最近mergeされていたので使ってみました。 カーソルを置いて実行 実行、実行、実行。すこしずつ広がってく。 perlのシジルなどにある程度うまく対応してくれるので便利でした。

    expand-region.elでperlのコードの範囲選択 - $shibayu36->blog;
  • 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;
  • greasemonkey内でjQueryを使う - $shibayu36->blog;

    久々にuserscript書こうと思って、greasemonkey辺りを触ってた。最近chromeではjsshellとか言うのがあるらしいけど、firefoxだったら今もgreasemonkeyで書いたらいいんだろうか。いまいちよくわかってない。 それはともかくuserscript内でjQueryとjQuery UIを使いたかったのでいろいろ調べた。 基 userscriptでは最初の部分にいろいろ書くと、どんなURLで読み込むかとか設定できる。そこで@requireを使っておけばとりあえず、jQueryを読み込んで使うことができる。 // ==UserScript== // @name Script Name // @description Script Description // @namespace http://saficion.com/ // @include http://

    greasemonkey内でjQueryを使う - $shibayu36->blog;
  • Qudo, daemontools, capistranoを使ってWorker処理の仕組みを作る - $shibayu36->blog;

    最近PrePANの開発を手伝っていて、Workerの仕組みをQudoで作りました。初めてWorkerの仕組みを一から作ったのでメモしておきます。 Worker処理に必要な部品、それぞれのQudoでの実装、Workerプロセスを管理するためのdaemontools、capistranoでのdeployという順番で書いていきます。 Workerとは ざっくり言うと非同期に色々実行するための仕組みです。perlだとTheSchwartz、Qudo、Jonkとかがあります。 Worker処理に必要な部品 今回作ってみて、Worker処理は大きく分けて次の三つくらいのものが必要だと分かりました。 ApplicationからJobをinsertする部分(Qudo) 実際のJobの処理(Qudo::Worker) Jobの実行を管理して、Jobに処理を委譲する部分(Qudo, Qudo::Paralle

    Qudo, daemontools, capistranoを使ってWorker処理の仕組みを作る - $shibayu36->blog;
  • 福島原発以上に危険性のある高速増殖炉もんじゅで今起きていること - $shibayu36->blog;

    いつもはこのブログでは、技術系の話しかしていないのですが、今回はちょっと変わって、今話題になっている原子力発電所の話を書きたいと思ってます。自分で調べてみると「高速増殖炉もんじゅって危ないな」ってことに気づきました。福島原発も難しいことになっていますが、もんじゅも現在も危険な状態になっています。それについてまとめてみました。 非常に長文になりましたので、時間があるときに読んでいただけるとありがたいです。特に福井県の方には自分たちの県のことなので読んでもらえたらと思います。 前置き まずこの内容について書きたくなった理由です。僕は福井県勝山市の出身で、福井県には多数の原子力発電所があります。これまでは原子力発電所については全く知識がなかったのですが、今回の福島原発での事故をきっかけに、やはり原発はある程度の危険性があるということに改めて気づき、原子力発電所について調べてみることにしました。そ

    福島原発以上に危険性のある高速増殖炉もんじゅで今起きていること - $shibayu36->blog;
  • Web Applicationを綺麗に設計するためのMVACという考え方 - $shibayu36->blog;

    【2016/03/04追記】以前まとめたこのMVACという名前の設計は既に古くなっており、今はこのようなアーキテクチャで設計していません。 こんにちは。最近ははてなでMVACというアーキテクチャに則って開発をしているのですが、ようやく意味を理解できてきました。そこで今回は「Web Applicationを綺麗に設計するためのMVACという考え方」について、サンプルを交えながら説明していこうと思います。かなり長くなってしまったので、時間があるときにでもどうぞ。 MVACって? データソースやロジックを扱う「Model」、表示・出力を管理する「View」、複数のModelとControllerをつなぐApplication、ユーザのリクエストなどを受け取りViewやApplicationを制御する「Controller」の4つの要素を組み合わせてシステムを実装する方式。MVCをさらに抽象化した