タグ

ブックマーク / tagomoris.hatenablog.com (23)

  • 専門用語を並べてしゃべる専門家は許せない、という人は愚かである、という話 - たごもりすメモ

    ちょっと最近腹に据えかねる記事がネットで散見されるので敢えてアレなタイトルで、よろしくおねがいします。 なおこの記事は、自分はソフトウェアエンジニアリングの専門家であるので、そのような領域を大雑把に想定して書かれております。が、たぶん他の専門領域においても似たような状況なのではないかと推察しております。 専門用語ばかり使って会話するような人は当のプロではない という言説を最近ちょくちょく見ますね。曰く、普通の人に説明できないようではダメだ。曰く、普通の人でも重要性が理解できないように話せないということは、実際にはお前のやっていることは重要ではないのだ。曰く、専門用語ばかりで会話するようでは実際の能力はわからない、専門用語などわからなくても当に能力がある人にはあるのだ。 んなわけねーだろ。 専門家というのは、非専門家には扱えない問題を扱う専門家だから専門家として働けていて、それなりの待遇

    専門用語を並べてしゃべる専門家は許せない、という人は愚かである、という話 - たごもりすメモ
    umiyosh
    umiyosh 2016/12/05
  • 続: OSSプロダクトとコミュニティの話 - たごもりすメモ

    先日書いた通りYAPC::Asia Tokyo 2015でOSSの開発とメンテナンスについての私見を話したところ、会場で id:t-wada さんから強烈な質問と、その後にまとまった量のエントリがきた。 t-wada.hatenablog.jp t-wadaさんの問題意識については上記エントリを読んでいただくとして、これに関連してYAPC::Asia期間中にいろいろな人と話したこと、およびその後に考えたことなどをまとめて書き下しておこうと思う。 明快な結論は無い。無いが、自分にとってのなんとなくの指針のようなものには多分なっており、こういうことを考えて自分はこれからコードを書くんだろうな、という気がする。 なお前提として自分がYAPC::Asia Tokyo 2015で話した内容がベースにあるので、できればそちらを把握しておいてほしい。t-wadaさんのエントリにあるメモは話した内容をよく

    続: OSSプロダクトとコミュニティの話 - たごもりすメモ
    umiyosh
    umiyosh 2015/08/31
  • Docker 1.8 に Fluentd logging driver が入りました - たごもりすメモ

    以前に書いた話の続きなんだけど、Docker 1.8が出た。 blog.docker.com で、それに Fluentd logging driver が入っている。これで Docker container で起動したプロセスのSTDOUTやSTDERRを直接Fluentdに向けて投げることが可能になった。Dockerにpull-reqを送ったのは初めてだったんだけど、無事マージされてリリースまでこぎつけたので、当に出たときはほっとした。途中だいぶ大変だったので……。 Collecting All Docker Logs with Fluentd | Treasure Data Blog 5 Use Cases Enabled by Docker 1.8’s Fluentd Logging Driver | Treasure Data Blog Treasure Data blogで既に

    Docker 1.8 に Fluentd logging driver が入りました - たごもりすメモ
    umiyosh
    umiyosh 2015/08/24
    Docker 1.8 に Fluentd logging driver が入りました - たごもりすメモ
  • マウンテンビューの片隅で意識低く短期間滞在を生き抜くためのノウハウ - たごもりすメモ

    自分もシリコンバレーはマウンテンビューに社があるベンチャーに就職して仕事でカリフォルニアの青空すばらしい! とか言っているからにはこの地域でいかに生き抜くべきかみたいな意識の高いことを書こうかと思ったが、青空を見ながらも既にビールが入っていて到底無理そうだった*1。 なので、シリコンバレーとかベイエリアなんて風呂敷を広げず、マウンテンビュー、しかもダウンタウン近くではなくSan Antonioという微妙に離れた田舎でクルマ無しにショートステイを無事生きるにはどうすればよいかについて書き残そうと思う。 そんなニッチな文書書いてどうするんだという話はありそうだが、少なくともこれから東京で入社してくる同僚のためには役に立つ……はずだ。 前提 San Antonio Mountain Viewというところにオフィスがあって、そこに徒歩で通えるあたりのホテルもしくはAirbnbに宿泊すると思いねえ

    マウンテンビューの片隅で意識低く短期間滞在を生き抜くためのノウハウ - たごもりすメモ
    umiyosh
    umiyosh 2015/04/13
  • serverspecのアーキテクチャ - たごもりすメモ

    serverspecは以下のようなソフトウェアですね。 サーバがどのような状態かをRuby DSL(RSpec記法)で記述する 記述されたspecの状態になっているかどうかをチェックする チェックはローカルマシンに対して行われるか、もしくはSSHを経由してリモートサーバに対して行われる チェックはOSコマンドを叩くことによって行われる これがどのように有用なのはかもうあちこちに書かれているので置いておいて、アーキテクチャを理解すると、以下のようなことがわかります。 specの実行にはRubyが必要 チェック対象サーバにはRubyは必要「ではない」 なので、チェック対象サーバの状態を取得するためにRubyの機能が問題になることはありません。もしうまく状態をとれていない項目があればそれはspecの書き方が悪いか、あるいはOSコマンドに落とす部分(matcher)がうまく作れていないかなので、ど

    serverspecのアーキテクチャ - たごもりすメモ
  • 「Serverspec」の話 - たごもりすメモ

    著者の宮下さんから送っていただきました*1。ありがとうございます。 o'reillyに電子版もありますね。 送っていただいてからちょっと私事でばたばたしていたら大量にレビューが書かれているので、どう紹介したものかと思っているうちに更に日が経ってしまった。 他の多くの人が書いている「まさにServerspec作者にしか書けない内容だから必見」というのは同意する部分しかないんだが、自分が同じこと書いてもなあ。 ということで、ちょっと視点を変えて「なぜServerspecが必要なのか」について書こうと思う。……と思ってここまで書いたんだが、このServerspecにも書いてあったしもう一度確認しよう、と思って読み直してみたところ、自分の考えていたことが全部書いてあった。 1.4 Serverspecの必要性 (p8) Serverspecって当に必要なの? という意見もよくTwitter等で

    「Serverspec」の話 - たごもりすメモ
    umiyosh
    umiyosh 2015/02/09
  • 社内ITシステムを構築・運用するのに最重要な3つのポイント - たごもりすメモ

    自社で使用するシステムを開発する、とする。 このとき迂闊にやっていると、気付いたら過去に構築したシステムのメンテナンスにばかり時間をとられ、新しいコードがぜんぜん書けていない、という状況に陥ることがある。 こうなると地獄だ。新規の興味深いコードを書くなんてとんでもない、という状態になる。メンテナンスコストを下げるためのコードすら書けなくて永遠に悲惨な撤退戦を繰り返すことになる。絶対に避けなくてはならない。 ということで、自分が心掛けていることをざっと書く。 全く手を入れずに動き続ける状態を最初に作る もちろんシステムというものは生き物なので、ある程度のメンテナンスコストが必要になる。特に会社というものは生き物なのでシステム周囲の環境は常に変化する可能性がある。データ連携している別のシステムの仕様が変われば、当然そのデータを利用する側も対応しなければならない*1。 ということで、システムには

    社内ITシステムを構築・運用するのに最重要な3つのポイント - たごもりすメモ
    umiyosh
    umiyosh 2015/02/03
  • 退職します - たごもりすメモ

    先にまとめ 現在の勤務先を退職することにしました。日が最終出社日です。 次はまだ決まっていません。というか、どことも具体的な話はまだしていない、という段階です。面白そうな職場はどこにあるかなと探している段階ですので、魅力的なところに心当たりがある方はぜひご連絡ください。色々な人と話ができるといいなあと思っています。 現職について 11月半ばくらいまでは転職はまったく考えていませんでした。が、その頃の世間の技術的な流れなどを見ていて、ちょっと技術的に異なることをやろうかなあ、と考えたのが直接的な理由です。今後どうするかを考えたとき、せっかくなら働く環境なども変えてしまった方がこれからの人生が刺激の多いものになりそうだということで、現職を退職することを決めました。 やりたいことを変えるだけなら社内でやればいいだろう、という話を会社側からはされましたし、もっともなことでもあるのですが、同時に前

    退職します - たごもりすメモ
    umiyosh
    umiyosh 2015/01/28
  • ISUCON4 いってきた&勝ってきた! #isucon - tagomorisのメモ置き場

    連覇だ! ヒャッホウ!!! #isucon 2014で優勝しました - すぎゃーんメモ ISUCON4 で優勝してきました!!! #isucon - blog.nomadscafe.jp 特にkazeburoさんのエントリに最終的な状況についての詳細が書いてありますので、ぜひそちらもどうぞ。sugyanは自分で力不足とか言ってますが、ISUCON戦という場で、業務でほぼ使ったことがないはずのRedisメインのコード改造をごりごりやってちゃんと動かす人なので、チーム外のみなさんは騙されてはいけません。それできるの超すごいんやで。 主催のLINE株式会社、あれこれ提供いただいていたデータホテル改め株式会社テコラス様、問題作成担当 @mirakui, @rosylilly, @sora_h の3氏、当にありがとうございました。たのしかった! だいたいこんなんで 大雑把に時系列の経緯だけ書くと

    ISUCON4 いってきた&勝ってきた! #isucon - tagomorisのメモ置き場
    umiyosh
    umiyosh 2014/11/12
  • 業務とオープンソース活動の話 (日本OSS奨励賞 受賞報告にかえて) - たごもりすメモ

    先日書いたエントリでも触れたけど、日OSS奨励賞、というものをいただくことになりました。ご推薦いただいた方がいるということで、当にありがとうございます。 「第9回 日OSS貢献者賞・日OSS奨励賞」受賞者を選定 | 日OSS推進フォーラム で、せっかくの機会だし、普段思っていることを書いておこうと思う。この内容はほとんど将来の自分に対する自戒だ。アレな内容になることを申し上げておきます。先日に引き続いてアレですが、まあせっかくの機会なんですよ。ねえ。 ちなみに、ちょー長くなりました。あっはっは。 業務としてのオープンソース活動 自分はフルタイムのオープンソースコミッタではない。オープンソース活動に貢献すること、などという文言は自分の業務内容にはひと言も含まれていないし、自分が所属する部署の目標にも無い。自分の業務はあくまで自社サービスに貢献すること、自社サービスの開発および運用を

    業務とオープンソース活動の話 (日本OSS奨励賞 受賞報告にかえて) - たごもりすメモ
    umiyosh
    umiyosh 2014/02/28
  • 4年前、おれがSIerの片隅で、何者でもなかった頃 - たごもりすメモ

    今からちょうど4年前の2010年2月、某巨大SIerの片隅でExcelPowerPointばかりを眺めて過ごしていた頃、おれは仕事でも仕事以外でもコードなんかまったく書いていなかったし、GitHubのアカウントも持ってなかった。毎日見積書とWBSと納品書と請求書と、Excel方眼紙の詳細設計書と格闘してた。 当時おれは30歳だった。一度はプログラマとして生きるのは自分には無理だと思って入社したSIerで数年やってて、そこそこ成功した数年を送っているとは思っていたけど、でもやっぱり、そんな毎日に飽きていた。 技術力を重視とか言いながらプロパー社員にコードを書かせようとしない会社の方針にも、svnもgitも閉じられててガチガチに監視されたネットワークに繋がせておいてオープンソースがどうのと言う文化にも、手順や履歴を重視とか言いながらロクにバージョン管理システムを使おうとしない一部の同僚にも、

    4年前、おれがSIerの片隅で、何者でもなかった頃 - たごもりすメモ
    umiyosh
    umiyosh 2014/02/25
  • Fluentdとはどのようなソフトウェアなのか - たごもりすメモ

    Fluentd というソフトウェアがある。日国内ではそこそこ話題になってきたが、何ができるのか、何に使うと嬉しいのか、何に使えるのか、という点について詳細をよく知らないという人もおそらくまだ多いことでしょう。 なので、簡単にまとめる。 http://fluentd.org/ なお以下の個別項目ごとに書いていくが、その手前にまとめを置いておくので忙しい人はそれだけ読むとよい。インストールや設定については導入部分については日語の記事はもう多くあるので、触れない。 概要 できること ログの収集 センサデータ等の収集 汎用データ処理プロセッサとして 頻出ユースケース ログの収集 データの集約 簡単なリアルタイム集計 ソフトウェアとしての特徴 コア プラグイン 安定性 性能 開発体制 コミュニティ ぶっちゃけどうなの? まとめ 現時点で、複数の場所に分散したデータや常に増え続けるデータの安全な転

    Fluentdとはどのようなソフトウェアなのか - たごもりすメモ
  • Linuxサーバのディスク容量減少アラートが飛んできた!ってときにどう対処するか - たごもりすメモ

    完全に このエントリ のネタパクりです。すいません。 何に使われてるかわかったもんじゃないマシンとか開発用サーバとかだと超巨大なバイナリとか置いてあるかもしれませんが、プロダクション用のサーバでそういうことは無いとしましょう。 その場合、原因はだいたい以下のどれかです。www/appとdbが別マシンに分かれてる場合は更に絞り込めますね。 wwwサーバやappサーバ ログ 圧縮してあるが保存世代数が多くて厳しいケース 圧縮し忘れてるケース 圧縮どころかローテーションすら忘れてて1ファイルどかんと存在するケース ローテーションがうまくいかなくて deleted ファイルなケース tmpデータなど(app) キャッシュサーバのディスクキャッシュ dbサーバ データ実体 (ib_data) バイナリログ ログの場合でも、ディスク上のどこにログが書かれてるかは色々なパターンがある可能性がありますね。

    Linuxサーバのディスク容量減少アラートが飛んできた!ってときにどう対処するか - たごもりすメモ
  • dmmのエンジニアと話をしてみたいという話(追記あり) - たごもりすメモ

    dmmは世の中のオトコノコにとっていろいろと言及するのに躊躇いつつ誰でも知っているアレなわけです。で、それなりの規模のWebサービスの裏側を見たことがある人なら誰でも、dmmの裏側はきっと物凄いことになっているに違いない、ということが想像がつくわけですね。 簡単に思い付く範囲でも以下のようなものがあります。 膨大な画像(サムネイル)および実コンテンツ(画像、動画、ソフトウェア圧縮ファイル)を配信するトラフィック しかもトップ数パーセントだけではなく、おそらくかなり裾野が広いトラフィック 膨大な商品の高速な列挙・表示 膨大な商品に関するタグつけ 膨大な商品に関する自然言語による全文検索 全トラフィックにおける膨大な量の課金・決済トランザクション 実物の通信販売に決済結果を載せる流通関連の問題 大勢のユーザに対して膨大な商品から適切に行うためのレコメンデーション これだけのことをやっているから

    dmmのエンジニアと話をしてみたいという話(追記あり) - たごもりすメモ
  • MessagePackのIETFへの提案に関する困惑 - たごもりすメモ

    MessagePackというオープンソースプロジェクトの現状と IETF による標準化について、それが果たして正しいのか、と困惑せざるをえない事態が起きているので、それについて簡単に書く。何が起きているのか知らない人々に少しでも知ってもらえたら嬉しい。 なお、自分はMessagePackのユーザであって開発者ではない。MessagePackを使ったコードを書いて動かしているが、MessagePackそのもののデータフォーマットについて詳細まで知っているわけではないし、MessagePackの改善については特にいいアイデアを出せる気もしない。 現バージョンのMessagePackについてとりたてて不満はなかったが、最近文字列型を加えよう、あるいはもっと楽に文字列を扱えるようにしよう、という話が出てきた。JSON的に楽に扱えて更にバイナリデータを投入できるフォーマットの需要そのものは理解できる

    MessagePackのIETFへの提案に関する困惑 - たごもりすメモ
    umiyosh
    umiyosh 2013/03/01
  • 知見はblogエントリに書けという話、またはWeb業界における @oranie 消失のリスク - たごもりすメモ

    このエントリに書くことはほとんど与太話なのであまり真面目に受け取ってはいけない。 特定のツール/ソフトウェア/業界であれこれやっていてTwitterに何となく書いたりしていると、かなり詳しい人からダイレクトに反応があって議論が進み仕事も進んでみんなハッピー、ということがある。自分だけじゃなくて、割と周囲を見てても起きてるなーと思う。 特に、だいたい詳しい人とかはそれぞれお互いのやりとりも見てるので、後日になって「あの人とあの人がこんな話を」というと、みんなけっこう覚えてて、ああお仕事の役に立ってますね、ソーシャルネットワーク万歳! となる。 が、これ、実際あまりよくない。tweetは流れちゃって後から追いにくいし、その時に両方をfollowしてないと会話が追えないし、まとめて集積されないと多少その道に詳しい人でないと全体像をとらえるのが難しかったりする。 これらの問題は特にできたばかりのソ

    知見はblogエントリに書けという話、またはWeb業界における @oranie 消失のリスク - たごもりすメモ
    umiyosh
    umiyosh 2012/10/24
  • PerlでSTDIN/STDOUTを任意のファイルハンドルに置き換える - たごもりすメモ

    いま書いてるコードで、forkしてexecするんだけど、execする前にSTDIN/STDOUTを任意のファイルハンドルに置き換えたいなー、もっというとexecするプログラムのSTDINにソケットのREADから流れてくるデータを流し込んで、STDOUTの出力をソケットのWRITEに流し込んでやりたいなー、というようなことを考えていた。 で、これが例えば今のプロセスのSTDOUTの出力をファイルに置き換えるには、以下のようにすればいい。 open(STDOUT, '>', '/path/to/file'); シェルスクリプトでも簡単。*1 exec >> /path/to/file さて、STDIN/STDOUTとconnect済みのソケットを結合したい。connect済みのソケットはファイルディスクリプタは持っているがファイルパスを持っていない、ので、普通にopenし直すだけではうまくいか

    umiyosh
    umiyosh 2012/09/18
  • Fluentd meetup in Japan 2 にいってきた #fluentd - たごもりすメモ

    Fluentd meetup in Japan #2 #fluentd on Zusaar ふらふらとお気楽に参加してきた。当方ささやかながらプラグインを作ったりしているので、他のひとがどのように使っているか、どのようなプラグインが他の人によって使われているか、あたりにたいへん興味があったので、そういう話をかなり聞けたのがすばらしく有益だった。主催者の方々、スタッフの方々、会場提供のグリーの方々、ありがとうございました。 以下だらだらとセッションごとに感想めいたものを書く。 「Fluentdの現在と未来」by @frsyuki 会場のFluentd利用者率が6割だか7割だかでびびる。当に? みたいな。あと日語ドキュメントなんていらんかったんやー、俺達は間違ってなかったんやー、と安心したりする。*1 Fluentd次期バージョンの話、じつはこれをメインで聞きにいったけど、既にTwitte

    Fluentd meetup in Japan 2 にいってきた #fluentd - たごもりすメモ
    umiyosh
    umiyosh 2012/08/24
  • Hive Client Webアプリケーション shib をつくった - たごもりすメモ

    (2013/04/02追記 see: http://d.hatena.ne.jp/tagomoris/20130402/1364898063 ) まだ完成度がいまいちだからなーと思ってエントリ書いてなかったんだけどLTでしゃべっちゃったので、ちゃんと書いておく。 Hiveにクエリを発行して結果を確認するためのWebアプリケーションを社内用途で作ってるんだけど、普通に他でも使えると思うので公開してあります。 tagomoris/shib · GitHub シブ と読みます。 セットアップ方法はドキュメントを参照のこと。起動してブラウザでアクセスするとこんな画面が出てくる。 使いかたは見ればわかる、と思う。たぶん。クエリは参照専用(SELECTのみ)。 __KEY__ とか __KEY1__ とかがプレースホルダですよってくらいかな。エディタ内でプレースホルダを書くとプレースホルダを置換する値

    Hive Client Webアプリケーション shib をつくった - たごもりすメモ
    umiyosh
    umiyosh 2012/08/18
  • 尊重されたいすべてのソフトウェアエンジニアへ - たごもりすメモ

    自分はソフトウェアエンジニアとして毎日の糧を得ている。今のところはサラリーマンエンジニア以外の存在になる予定はない、が、とはいえ唯々諾々とつまんない仕事ばっかりやる毎日はできればごめんだと思っている。コードを書くのは楽しいからコードを書ける仕事をしたいし、特に面白い問題やまだ誰も手をつけてなさそうな問題を解決する仕事ができれば最高だ。 つまり、そう、尊重されたい。自分のやれること、やりたいことを尊重されるようになりたい。自分がやった仕事には価値があると思われるのは嬉しいし、そのように(勤務先以外の)他人から認められれば面白い話も聞けるようになるかもしれない。尊重されるソフトウェアエンジニアになれれば楽しそうだ。 尊重されるソフトウェアエンジニアであれば、もしかしたら自分の仕事についてある程度の自由が効くかもしれない。突然わけのわからない政治でがんじがらめの炎上プロジェクトPMをやってこい

    尊重されたいすべてのソフトウェアエンジニアへ - たごもりすメモ
    umiyosh
    umiyosh 2012/06/09
    良エントリ。#nf