タグ

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

  • PathtraqというLifeLogサービスを作った - たごもりすメモ


    最近何をやっていたかというと、タイトルの通り、Pathtraqというサービス、iPhoneアプリを作っていた。どんなサービスかと聞かれるとLifeLogというのが一番適切だと思うけど、LifeLogにも種類があって、これは位置情報を記録して検索するサービスになる。 https://pathtraq.tagomor.is/ PathtraqApp Satoshi TagomoriProductivityFreeapps.apple.com どういうためのものかというと、普段生活したりどこかに行ったりして、以下のようなことが気になる方向けです。 この場所/店/街、最後に来たのいつだっけ?前に飲みにいってふらっと入ったあの店、どこにあった何ていう店だっけ?前にあそこからあっちに移動したとき、どのくらい時間かかったっけ?なんかさあ、この程度のこと、全部記録とってあれば簡単にわかるはずなんだけ
    PathtraqというLifeLogサービスを作った - たごもりすメモ

  • 象印の加湿器が最高で当面これしか使いたくないという話 - たごもりすメモ


    ちょっとTwitterに書いたら食い付いてくる人が多かったので、ではアピールしとこうと思った。 象印の加湿器、とにかく手入れが簡単でこれ以外の加湿器はもう二度と買う気がないというくらい最高— tagomoris (@tagomoris) 2023年1月7日 TL;DR 衛生面などを考えると加熱式加湿器*1を使いたい 加熱式加湿器は加熱部に残留物が結晶化して固まるので手入れがめちゃ面倒 象印のやつは電熱ポットと同じなので、たまにクエン酸ぶちこむだけで超ラク、最高です 加湿器運用の手間を減らしたい人にとにかくお勧めです 自分が使ってるのはこれ。今年大きいのを買い足した。旧モデルの小さい方とあわせて2台とも使ってます。 EE-DC35・50 | 加湿器 | 生活家電 ｜ 商品情報 ｜ 象印マホービン 加湿器を加熱式のに替えるとき、某社従来型*2と象印の(2020年モデル)と2台買ったんだけど、手
    象印の加湿器が最高で当面これしか使いたくないという話 - たごもりすメモ

  • 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 が入りました - たごもりすメモ

  • 小中規模のIT系企業における技術的選択と雇用戦略に関する雑感 - たごもりすメモ


    でっかい主語で入ったが、要するに2月にあちこち会社巡りをしたときに感じたことについてつらつら書こう、というのが目的。 特定の会社について書いてもしょうがないので、あれこれ*1回ったうちから少なくとも2〜3ケースで該当するなあ、と思ったことについて書く。特定の1社のみに該当する事項はこのエントリにはひとつも出てきません。 またエントリの主旨からして超上から目線になりますが、どうかご容赦ください。 これから成長が本格化するのでインフラを支えられる人材がほしい 正直に言ってこれが一番多かったパターン。スタートアップ的にサービスを作ってきたがその一方でデプロイや監視などの運用まわりが後手後手になっており、そのあたりを支えられる人物がほしい。 話としてはわかるのだが、気になったのは、これを聞くとき、詳しい内容を突っ込んでみると、どうも実際にはそう困ってはいない、というケースがほとんどだったように思え
    小中規模のIT系企業における技術的選択と雇用戦略に関する雑感 - たごもりすメモ

  • Webエンジニアが目を通しておきたいインフラの基本の本 - たごもりすメモ

    「Webエンジニアが知っておきたいインフラの基本」を著者の馬場さんから献本いただきました*1。ありがとうございます。 ITインフラの設計やら構築やら運用やらに関わりながら仕事をするようになってそれなりの年数になった。日頃おろそかにしている部分もあれば専門だと思って自信をもってやれることもある。その中でたまに思うのは、何が当たり前で何は当たり前ではないのか、ということがよくわからなくなってきたなあ、ということだ。 障害対応時の心構えは？ そもそもシステムメンテナンスにおける心構えとは？ Webアプリケーション基盤の設計方法は？ 非機能要件にはどのようなものがあるか？ パフォーマンスとは何を指すのか？ どんなサーバにも入っているツールで調べものをするときの鉄板は？ サーバのパフォーマンスを示すグラフの見方は？ どのような兆候が出ていたら注意しなければならないのか？ どの数字にどういった意味があ

    Webエンジニアが目を通しておきたいインフラの基本の本 - たごもりすメモ

  • Reverse Proxyがなぜ必要か、勝手に補遺 - たごもりすメモ


    ﹁全体のリソース効率を上げましょう﹂というためのものである。Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー これは完璧に正しくて、ただ﹁リソース効率﹂という概念はあまり具体的な想像が追い付かない人がいそうだなと思ったので、ちょっとだけ補足しようと思った。Reverse Proxyを入れることでリソース効率の向上を狙うんだけど、それは以下のような複数の場面におけるそれぞれのリソース効率向上を複合的に狙うものだ。 通常時のトラフィック配信におけるCPU・メモリ使用率を最適化する バースト時(過負荷時)のトラフィックをより細かく制御可能とする 障害時におけるダウンタイムおよび総合的な計算・配信能力の低下を極小化する 多数のサーバによる構成全体を増強・入れ替え・移動あるいは削減する際の自由度の向上を狙う 簡単にコンピュータの性能だけで言うと最初の項目だけをリソース効
    Reverse Proxyがなぜ必要か、勝手に補遺 - たごもりすメモ

  • 4年前、おれがSIerの片隅で、何者でもなかった頃 - たごもりすメモ


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

  • クラウド環境の設計指針をどう決めるか - たごもりすメモ


    クラウドに限らず、データセンタの設計全般に言えることだけど。 コンピューティング基盤をどのように設計するかには根本から異なるアーキテクチャが様々あって、ある特定の方向のアーキテクチャについても実現するためのソフトウェアやハードウェアに様々なものがある。 合議制で決めてはいけない。何を採用するか、どのように設計するかについては、誰かが英知をもって決断するべきだ。それも可能な限り素早く。 今更言うまでもないことだが、この世界は技術の変化が非常に速い。おそらく3年経てば優位な技術は入れ替わっていて、何か新しいトレンドとか技術要素だとかいったものが登場しているだろう。 そんな中で何を採用するかについて、長い時間をかけるのは簡単だ。3年かけて実機を多数揃えて比較検討すれば、検討開始からの3年間で何が優位だったかが確実にわかるだろう。 おそらくその頃には別の技術が登場し、更に3年の比較検討が必要になっ
    クラウド環境の設計指針をどう決めるか - たごもりすメモ
    sawarabi0130
    sawarabi0130 2013/12/20
    [インフラ
    リンク

  • Fluentdとはどのようなソフトウェアなのか - たごもりすメモ


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

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

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

    Linuxサーバのディスク容量減少アラートが飛んできた！ってときにどう対処するか - たごもりすメモ

  • Perlでコマンドラインオプションの解析に Getopt::Long を使う時、絶対に忘れてはいけない引数 - たごもりすメモ


    Perlでコマンドラインオプションをparseしようと思うと組込みモジュールとしてはGetopt::Std とGetopt::Long がある。が、long style option *1 つまり --option-name のようなオプションを解釈してくれるのはGetopt::Long だけだ。なので普通はこちらを使おう。 ただし 絶対にデフォルト、つまり以下のようにして使ってはいけない。 use Getopt::Long; my (@primary, @secondary, $silent); GetOptions( "server-primary|p=s" => \@primary, "server-secondary|s=s" => \@secondary, "silent|S" => \$silent ); これダメ！ 絶対ダメ！ 死ぬ！ 最初に結論を書く 必ず以下のように
    Perlでコマンドラインオプションの解析に Getopt::Long を使う時、絶対に忘れてはいけない引数 - たごもりすメモ

  • #java_ja で例外とロギングについて勉強会をやるというのでいってきた＆飛び込みLTやった＆運用の視点から見たアプリケーションのログについて - たごもりすメモ


    LOG.debug("nice catch!") - connpass 2012/06/27 java-ja ﹃LOG.debug("nice catch!")﹄#java_ja #javaja - Togetterまとめ blogエントリを書くまでがjava-jaだと聞いたのでとりあえず書く。超まとまってません。各スピーカーの話の内容については他の人のblogに(たぶん)書いてあるのでそっちを見るとかTogetterを眺めるとかすればよいのではないでしょうか。 主催のみなさま、および会場提供のGREEさま、ありがとうございました。そういえばGREEでの勉強会って初めて参加した気がする。六本木ヒルズの入館、だいぶ簡単になりましたね。 いってきた どっちかというとアプリケーションのコード書く人が多かったんですかね。という感じで、アプリケーションコードからいかにして例外を投げるか、それをどのよ

  • 尊重されたいすべてのソフトウェアエンジニアへ - たごもりすメモ


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

  • サラリーマン人生における希望と絶望 - たごもりすメモ


    自分のささやかなサラリーマン人生において、大きい会社(の一部)も小さい会社も見てきたけれど、そこで気付いたことがあって、そんなもやもやが堆積してきたのでここに吐き出す。たぶんまとまらない。 サラリーマンには2種類いる。 会社を肯定する奴と文句ばかり言う奴、ではない。会社の文句を言う一方、同じ口で会社を肯定することも言う奴、と、会社のことを肯定も否定もしない奴だ。*1 自分の所属する会社に対して不平を言う人はけっこういる。取締役会の決めることや人事異動や予算配分やプレスリリースにしじゅう文句を抱えていて、お昼休みや飲み会やタバコ部屋であーだこーだいう話をする人はたぶんどこにでもいる*2。 曰く、なんで会社が利益を出せているかが分からないくらいだ、会社がなんで存続できているかが不思議だ、あの上司はなんにもわかってない、今度のアレは失敗するに決まってる、あそこのアレがいつまでも改善されなくてうん
    サラリーマン人生における希望と絶望 - たごもりすメモ

  • xargs を使ってカジュアルに並列処理 - たごもりすメモ


    シェルからでも重い処理というのはちょこちょこあって、例えば超デカいログファイルを移動して圧縮したりというお仕事は世界中のあらゆる場所で毎日行われていたりする。コマンドラインからでも大量の圧縮済みログファイルをいっぺんに展開したい、とか。 あるディレクトリ以下に存在するたくさんのファイルを(圧縮済みのものを除いて)全部bzip2圧縮したい！と思ったら、とりあえずさくっと次のようにコマンドラインで叩けばいい。 $ find . -not -name '*.bz2' | xargs bzip2これで、まあそんなに問題なく効率的にbzip2圧縮ができる。だがしかし。 最近は複数コアのCPUが普通に転がってるし、あまつさえHyperThreadingが有効になってたりしてOSから見える論理CPU数がハンパない。普通に8とかある。その一方で複数コアを使用してくれるコマンドというのはあんまりなくて
    xargs を使ってカジュアルに並列処理 - たごもりすメモ

  • RAIDレベルの話: 1+0と6はどっちが安全か？ - たごもりすメモ


    仕事でちょっくら12台のHDDを使ったRAIDアレイを組むんだけど、その折にちょうどTwitterで﹁RAID-1+0にしないとRAID-6とか怖くて使えませんよ！﹂というウソ八百な内容のWebページのURLを見掛けたので、いいかげんそのような迷信が消え去ってもよかろうと思って書くことにした。1重ミラー設定のRAID-1+0は安全性においてRAID-6に劣る。ただし、正しく運用されている場合に限る。*1 知っている人はずっと前から知っている事実ではあるんだけど、某巨大SIerなんかでも高い方が安全に決まってる的な残念な脳味噌の持ち主がいっぱいいて﹁いやあデータの安全性を考えるとRAID-1+0﹂とか考えもなしにクチにし、そっちの方がディスクがいっぱい売れて嬉しいストレージベンダーもニコニコしながら否定せず売りつけて去っていくといううわなにをす(ryまあそんな感じで。ちなみに正しくない運
    RAIDレベルの話: 1+0と6はどっちが安全か？ - たごもりすメモ
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.