タグ

ブックマーク / songmu.jp (7)

  • コミュ力が無いのはいつだって自分 | おそらくはそれさえも平凡な日々

    突然何を言い出すのかという話ですが、対話相手にコミュニケーション能力を求める醜さについて書きたくなったので書きます。 僕はオタクだったしスクールカーストで言うと下の方を彷徨ってきた。地元でもいろいろあって浮いていた。新卒時の就活も散々だった。なので、コミュ力がないことは自覚しているし、だからこそ「コミュニケーション能力」という言葉には警戒心があります。 比較的マイノリティであったことが多かった経験上分かったのは、相手とコミュニケーションが取りづらいな、と思うときは、そもそもプロトコルが異なる、ということです。 これは、話している自然言語が違うようなものだと考えるとわかりやすい。例えば、自分が日語しか話せず、相手がロシア語しか話せないのであれば、まともなコミュニケーションが成り立たないのは明らかです。そして、その時に、日語が話せない相手にコミュ力がないと思うような人はいないでしょう。 そ

    コミュ力が無いのはいつだって自分 | おそらくはそれさえも平凡な日々
  • Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々

    Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな

    Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々
  • Redisアプリケーションパターン | おそらくはそれさえも平凡な日々

    この記事は、はてなエンジニアアドベントカレンダー2016の12日目の記事です。 先日こういうツイートをしました。 Redisはキャッシュ用途のミドルウェアだと思わない方が良いと思う — songmu (@songmu) 2016年12月10日 言いたかったのは、Redisはキャッシュのためだけのミドルウェアだと誤解されがちなのですが実際はそうではないということです。実際、公式サイト を見に行くと以下の様なことが書かれています。 Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. つまり、Redisは多彩なデータ構造を保持できるインメモリーのデータストアで、様々な活用法があり、キャッシュとして「も」使える、とい

    Redisアプリケーションパターン | おそらくはそれさえも平凡な日々
  • godzilというGoのオーサリングツールを作っている | おそらくはそれさえも平凡な日々

    https://github.com/Songmu/godzil Goのモジュール作成と、リリースをサクッとできる君が欲しくて作っている。作りかけだけど、すでに便利に使ってはいます。インターフェースは結構変わる可能性はあります。名前の通りかなりMinillaインスパイアです。 モチベーションとしては以下。 リポジトリ作る際に毎回適当な既存リポジトリからコピペするのに飽きた Go Modules時代になりツールじゃないライブラリもタグ管理した方が良さげになってきたのでリリース管理したい 今のところの使いかた モジュールの作成 % godzil new github.com/Songmu/oreore scaffoldingされて、git init && git add . される。あとは適当にremoteリポジトリを登録して開発してください。今のところGitHub or GHEで開発する前提

    godzilというGoのオーサリングツールを作っている | おそらくはそれさえも平凡な日々
  • Makefileを自己文書化する `make2help` | おそらくはそれさえも平凡な日々

    近年「タスクランナー」という言葉をよく耳にするようになりました。近年のWeb開発では、開発環境のセットアップ、依存ライブラリの管理、テストの実行、開発サーバーの起動、ビルド、デプロイ等等、とにかく気にしないといけないことが多いため、そういったタスクを一元管理してくれるタスクランナーは便利なやつです。 新しくプロジェクトに参加した際に、タスクランナーを見れば何をやれば良いのかだいたい分かるようになっているのが理想的だと思っています。 タスクランナーという言葉は主にJS界隈で使われており、そもそもタスクランナーなのかビルドツールなのかという話はありますが、ここでは便宜上それらをひっくるめてタスクランナーと呼ぶことにします。 gulp質的にはビルドツールですし。 Goの開発においては、タスクランナーとして、古き良きビルドツールであるところの make が主に使われます。 make も使って

  • Carton考2014 | おそらくはそれさえも平凡な日々

    こうするのがいいかなーと思ってる。経緯は端折って大枠だけ。Webアプリケーションプロジェクトの場合です。 cpanfileちゃんと書いてコミット 今やどこでもやってますね。scan-prereqs-cpanfileも便利です。 開発者は各自carton installでモジュールをインストール。プロジェクトごとにPerlをビルドしたりしてる場合は、cpanm --installdeps .でも別に良い。 CI環境でcpanfile.snapshotを作る CI環境は必ず以下のとおりとする。 番環境と同じアーキテクチャ 番環境と同じバージョンのPerl まっさらな状態(Globalに何のモジュールも入っていない) CIにcarton installもさせて、必要なモジュールをlocal/に入れてテストさせる。毎回サラからcarton installしてたら時間かかるので、git pull

    Carton考2014 | おそらくはそれさえも平凡な日々
  • horensoというcronやコマンドラッパー用のツールを書いた | おそらくはそれさえも平凡な日々

    リリースしました https://github.com/Songmu/horenso cron等、バッチジョブを走らせた場合にその結果通知やエラーレポートをどうするかは悩ましい問題です。ラッパースクリプトを統一的に噛ますのが常套手段ですが、そのためのツールとして、horenso というものをGoで作りました。報・連・相。その名の通り、実行ジョブの報告をつかさどってくれる君です。以下のようにして使います。 % horenso -r reporter.pl -- /path/to/job args... -- 以降に指定したコマンドが実行され、その結果がJSONとして標準入力経由でreporterに渡されます。reporterは実行可能なファイル、もしくはコマンドライン文字列であり、記述言語は任意です。reporterに渡されるJSONは以下の様なものです。 { "command": "per

    horensoというcronやコマンドラッパー用のツールを書いた | おそらくはそれさえも平凡な日々
  • 1