ブックマーク / satoru-takeuchi.hatenablog.com (50)

  • 健康第一、インプットやアウトプットは後。持続可能な生き方を - 覚書

    世の中たくさんのインプット、アウトプットの機会があります。勉強会に参加したり、そこで発表したり、記事やを読んだり書いたり…などなど。 SNSを見ると世間の多くの人はこういうことをしているように見えます。「自分もやらなきゃ」という気になってきます。 これらは自分のスキルを高めたり、同士を見つけたり、生きがいを見つけたりするよい手段だと思います。自分だけが嬉しいのではなく、 価値あるコンテンツを提供したり勉強会の運営を手伝ったりすれば、自分だけではなく周りの人もうれしいこともあります。 ただし、こういうことは、やればやるだけよいというわけではないと私は思っています。 人間は意図的に休んだり寝たりしていない限り、疲れます。いくら楽しくても心身ともに消耗します。なのでインプットやアウトプットは 自分が健康を保った上で、プラスアルファとしてやる程度といいと私は思っています。疲れてるときは、仕事が忙

    健康第一、インプットやアウトプットは後。持続可能な生き方を - 覚書
  • わたしの私用PCの開発環境 - 覚書

    わたしに声をかけてくれるIT技術者、とくに経験が浅い人に私用PCの開発環境は何を使っているかということをよく聞かれます。なにかの役に立つかもしれないので、環境を紹介しつつ、どういう思いでそうしているのかについても書きます。 私のバックグラウンドを説明しておくと、会社員として15年ちょっとLinuxカーネルの開発、サポート業務をしていました。その後6年くらい別のSaaS企業で自社インフラ用の分散ストレージの開発をしています。このストレージはLinux上で動作します。趣味ではLinuxカーネルやその周辺領域についての技術書を出したり記事を書いたり、YouTubeの動画を公開したりしています。つまりLinuxに非常に縁が深いです。 わたしはPCを2台持っています。一つめは普段使いのモバイルノートPC、もう一つはミニタワーのデスクトップPCです。ノートPCVAIO Zで、スペックを盛れるだけ盛り

    わたしの私用PCの開発環境 - 覚書
  • プログラミングを始めたころとは考え方が全然変わっていることに気づいてびっくりした話 - 覚書

    家にパソコンがはじめて来てから30年くらい、プログラミングを始めてから20年以上が経ちました。その間、IT技術に対する愛は変わらずに、ずっと走り続けてきました。では当時の自分と今の自分で何が違うのだろうと考えてみたところ、めちゃくちゃ変わっていたのでびっくりました。記事では何がどう変わったのか、それを見てなにを思ったかなどを書きます。 昔は次のようなこだわりがありました。 大きなものは一つの仕事をする単純で小さなツールを組み合わせて作るべし ソフトウェアは可能な限り設定可能になっていてほしいし、それを自分の好みになるまでカリカリチューニングしたい 可能な限りすべてキーボードだけで操作できるようになっていてほしい いわゆるUNIX哲学をはじめとして、いろんなやWebサイトなどに強い影響を受けていることがよくわかります。 ところが今は次のように全然違うことを考えています。 トラブルハマった

    プログラミングを始めたころとは考え方が全然変わっていることに気づいてびっくりした話 - 覚書
  • 誤りを認める練習 - 覚書

    明らかに誤ったことをしたのにそれを認められずに醜態をさらしている、場合によっては傷口を広げて自分を窮地に追い込んでいる人を大量に見てきた結果、「こうはなりたくないな」と思う気持ちがずっとありました。にもかかわらず、数年前に見事に過ちを認められずに、謝罪できずに無様な姿をさらしたことがありました。公の場でやったことではないし、もしかすると謝罪されるべきだった相手は気にしていなかったかもしれませんが、自分から見れば間違いなく無様でした。 こういうことがあって以来、誤りを認める練習をするようになりました。練習といっても、壁に向かって謝罪し続けるというような話ではなく、自分の言ったこと、書いたことが間違っていたとわかったら、何もしなくてもその場はやりすごせそうな小さなことでも即座に「これは誤っていた」と表明するということをやっています。小さな誤りを認められなければ、大きな過ちを犯したときにも認めら

    誤りを認める練習 - 覚書
  • ソフトウェア開発者のわたしが好きなコンピュータ以外の本 - 覚書

    2023/8/13 18:20 タイトル変更。「ソフトウェア開発者が好きなコンピュータ以外の」→「ソフトウェア開発者のわたしが好きなコンピュータ以外の2023/8/15 16;20 「敗者のゲーム」から「星を継ぐもの」までを追加 私はソフトウェア開発者です。このブログなり別の場所なりでコンピュータについての参考書を何度なく紹介してみました。記事はそれとはちょっと違って、私がこれまで出会ってきて感銘を受けたコンピュータに関係ないたちを紹介します。紹介順とお気に入り度は連動していません。思いついた順番に書いただけです。 ルワンダ中央銀行総裁日記 銀行家である筆者がルワンダという国の中央銀行総裁を務めていた時期のことについて述べたです。事あるごとに色々なところで紹介される有名ななので、名前は聞いたことがあるとか読んだことがあるとかいう人は多いかと思います。書の凄いところは2つあ

    ソフトウェア開発者のわたしが好きなコンピュータ以外の本 - 覚書
  • IT技術についての書籍を商業出版するか同人誌として出すか - 覚書

    IT技術者はさまざまなプラットフォームを通して情報発信して知見を共有するのが好きという印象が強いです。zennやqiitaといったサービスをはじめ、さまざまな場所で貴重な情報が無償で公開されているのは驚くばかりです。 情報発信を繰り返していくうちに自分のコンテンツを形にしたい、具体的には書籍を出したいと思う人も多いようです。そこで目の前に立ちはだかる壁のひとつが出版社から商業出版するか同人誌として出版するかという選択を迫られることです。記事ではそれぞれのpros,consについて、これまでに商業出版、同人誌出版の両方の経験がある筆者の意見を書きます。 結論から書きますと、わたしは以下のような考え方を持っています。 なるべくお金がほしいなら、あるいは世の中に広く情報を行き渡らせたいなら商業出版 ニッチで客層が限られるものについては同人誌 いずれにせよ普段から誠実な情報発信をし続けるとリーチ

    IT技術についての書籍を商業出版するか同人誌として出すか - 覚書
  • 情報発信に伴う負のリアクションについて - 覚書

    なんらかの情報発信をすると、いろいろなリアクションが返ってきます。記事ではこれら負のリアクションに怖気づかずに発信を続けたい人に、これまでに色々な記事を書き、かつ、殺害予告を含めた多種多様なリアクションを受けてきた筆者の考えかたを書いたものです。とくに情報発信を推奨するものではありません。やりたい人がやればいいだけです。 負のリアクションにはいろいろなタイプがあります。ここでは以下の三つのタイプについてのみ述べます。 馬鹿だのアホだのいう悪口 答えが無いものについての反対意見 誤りの指摘 複数のタイプが混ざり合ったものもあります。たとえば「ここの定義が間違えている。こいつは頭がおかしい」は誤りの指摘と悪口が混じっているといえます。 上記3つのタイプのうち、悪口については無視するといいと思います。なぜなら気にしてもとくにいいことはないからです。仮に相手にしてもとくにいいことはありません。発

    情報発信に伴う負のリアクションについて - 覚書
  • twitterでのふるまいで気を付けていること - 覚書

    twitterは有益なことが多々あるんですが、ちょっとしたことでストレスを溜めたり、他の人に害を及ぼしたり、身を滅ぼしたする可能性があります。それを避けるためにわたしが気を付けていることを書き連ねてみました。別に「みんなもこれやろうぜ!」とか「これをやったら必ずストレスフリー」とか言いたいわけじゃなくて、この中のどれか一つでもなるほどと思えば参考にしてもらえれば、という意図で書いてます。 自分の意にそわないこと、ばかげていると思っていることを「世の中にはこんなにけしからん人がいますよ、ひどいものがありますよ」とわざわざ紹介するのを避ける*1。「不快だ!」というだけでは不快の再生産になるだけかなと 特定の人物、事物をこき下ろすようなことはしない。単に好みでないというのもあるが、まわりまわって身を滅ぼすリスクもある。それは発言した瞬間だけではなく、何年も後になったときかもしれない。たとえば自分

    twitterでのふるまいで気を付けていること - 覚書
  • 「仮説の誤り」 != 「無駄」 - 覚書

    難しいことをしていた人が、それがうまくいかなかったときに「自分の立てた仮説は間違っていた、丸一日無駄にした」などといって落ち込んでしまうことがあります。しかし、それは違うよという話をします。別に物珍しい話ではないのですが、知らない人がかなり多いので、あえて書きます。 話を簡単にするために、「何らかの問題の原因を明らかにするために仮説を立てて検証したものの、うまくいかなかった」という場合をここでは考えます。たしかにこれは「仮説が間違っていた」*1とは言えるんですが、決して無駄ではありません。なぜかというと、これは原因を特定するためのたくさんある仮説の中の一つが誤りだとわかっただけで、その次は残った仮説の中から一つを選んで調査を継続すればいいだけだからです。つまり問題の絞り込みには成功して、調査は着実に先に進んでいるといえるのです。 過去事例をもとに具体的な話をしましょう。わたしはかつて、プロ

    「仮説の誤り」 != 「無駄」 - 覚書
  • ポイントカードとか電子マネーがめんどくさい - 覚書

    世の中にはポイントカードや電子マネーが大量にありますけどわたしは前者はスマホアプリを使うものを含め数個だけ、後者はモバイルSUICAだけを使っています。なんでそうしてるんだっけと整理したくなったのでつらつらと書きます。初めに断っておくと別に他の考え方を否定するつもりはないですし同意を求めるものでもないです。 要約すると「細かいことで頭と時間を使いたくない」です。 まずポイントカード。利点はカードによってさまざまあるものの、雑に書くと数%程度割引されるということです。それに対する欠点は、会計時にカードケースから該当するカードを出す手間がめんどくさいこと、および、かさばることです。これはカードの数が増えれば増えるほど、カードを使う頻度が高ければ高いほど顕著になります。これより単価も総額も安めになりがちな日用品を扱う店のカードは欠点のほうがかなり目立つので一枚も持たないことにしています。それに対

    ポイントカードとか電子マネーがめんどくさい - 覚書
  • べつにQiita使ってもいいんじゃないの - 覚書

    Qiitaは悪く言われがちです。よく聞く理由は次のようなものです。 記事の品質が低い 低品質なものが検索上位に来るので邪魔 これらからのコピペばっかでプログラミングしてるやつらが嫌い これらはごもっともだなあと思う反面、そこから一歩先に進んで「Qiita見んな」「見てるやつはエンジニア失格」とか言われるとちょっと違うかなあと思います。ここには良い記事もけっこう転がっているので、やりかたさえ気を付ければとても便利なサイトだと思っていますし、実際けっこう参照しています。 気を付けているのは次のようなことです。 記事の品質の問題 タイトルがそれっぽいものはとりあえず斜め読みしてみる 中身がスカスカだったり論旨が不明瞭だったり煽りっぽかったりする人は容赦なくブロック 検索の問題 文字列検索では、なるべく具体的、かつ、ひっかかる数が少なそうなものにする「kubernetesについて検索したけどk8s

    べつにQiita使ってもいいんじゃないの - 覚書
  • 一社員から見たサイボウズに対する印象 - 覚書

    はじめに 今朝twitterを眺めていると、現在私が勤めているサイボウズの綱島さんが書かれた以下のような記事を見つけました。 note.mu 気になる会社のことを調べる際に、よくある話。 「この会社のメンバーがどんな雰囲気なのか、もっと知りたいなぁー」 「でも、人事がいつも口にする "アットホームで風通しのよい社風" って、もう聞き飽きたよ…どうせ建前じゃないの?」 採用担当の僕は考えました。 「候補者の方々にサイボウズのことをもっと知っていただくにはどうしたら良いのだろう…?人事によるオフィシャルな情報発信もいいけれど、会社のいいところとか見せつけすぎてもぶっちゃけ引くしなぁー。もっとこう、サイボウズのメンバーが会社とか関係なく、素顔のホンネで話しているところをご覧いただいて、好きになってもらって、ジョインしてもらって…って感じのほうが好きだなぁ。なんかいい方法、ないかなぁー」 あ。メン

    一社員から見たサイボウズに対する印象 - 覚書
  • sshを使ってリモートマシンでコマンドを叩く際の注意点 - 覚書

    知ってる人には当たり前なのかもしれないですが、自分用のメモです。 先に結論を書くと次の通り。 sshでリモートマシンにログインするのではなく<ssh command>によってコマンドを叩く場合には、ttyが割り当てられない。sshに-tオプションを付与すると、端末を無理矢理割り当てられる cronなどのttyが割り当てられていない環境からは-tオプションだけでは不十分で、-ttオプションが必要 事の経緯は、固定IPアドレスが無い自宅マシン(回線はフレッツ光)にインターネットからアクセスしたいというものでした。DDNSを使うんではなく、固定IPを持っている自前VPSと"who am i"を使えば、簡単になんとかできるだろ、と思ったのが運の尽き。どハマリしました。 最初に思い描いたサービスは次の通りです。 自宅マシンからVPSにsshで定期的に接続して、IPアドレスを所定のファイルに書き込む。

    sshを使ってリモートマシンでコマンドを叩く際の注意点 - 覚書
  • Ryzenにまつわる2つの問題 - 覚書

    NOTE1: 2017/8/12に2つ目の問題について更新しました。ついに両方の問題が解決しました。 NOTE2: 2つ目の問題についてはすべての経緯をまとめた書籍があります。 4月にRyzenを積んだデスクトップマシンを買いました。その上で日課であるカーネルビルド&テストをした*1ことをきっかけに、2つの問題が発生しました。先代のCore i5を積んだマシンでは起きなかった現象です。 このエントリは自分用のメモがてら、新しいことがわかれば随時更新していきます。後者については9月に開催されたkernelvm北陸にて、ブログには書かれていない解析の詳細などについて発表してきました。 Ryzen segv battle from Satoru Takeuchi www.slideshare.net 環境 ハードウェア CPU: Ryzen 1800X Motherboard: ASUS PR

    Ryzenにまつわる2つの問題 - 覚書
  • 低レイヤ技術を間接的に仕事で生かしてきた経験の共有。元Linuxカーネル開発技術者の場合 - 覚書

    はじめに ITの世界で「低レイヤ技術」と呼ばれるものがあります。明確に定義されているわけではありませんが、アプリケーションのような直接エンドユーザに触れる部分ではなく、しかもなるべく生のコンピュータに近い部分、たとえばOSカーネルやコンパイラ、CPUを開発する技術などがあります。これらの技術に明るい人はそうそういないのですが、「やってみたい」という根強い人気があります。 学生のかたでもセキュリティキャンプなどで実際にある程度身につけてしまうような人もいます。そしてますますこの手の技術趣味としてのめり込んでいって楽しくなる…というところまではいいのですが、「ではこの技術を会得した先に何があるのか」と不安になる人も多いようです。とくに学生さんの場合は「低レイヤ技術を使って今後なんらかの仕事をして生きていけるのか?」といったことが気になるようです。今日もそのような話を少し耳にしたので、自分の経

    低レイヤ技術を間接的に仕事で生かしてきた経験の共有。元Linuxカーネル開発技術者の場合 - 覚書
  • タスク管理、スケジュール管理方法の共有 - 覚書

    タイトルの通り、わたしが何年もやってるタスク管理、スケジュール管理の方法を共有します。飽きっぽい、いろんなことを一気に覚えられない、並列作業が極めて苦手、という特性を持つ私向けに特化してます。似たような性質の人には役立つかもしれないと思って書きました。個々のツールの細かい使い方については説明しません。 まずは紙の手帳を使うのか、それともそれ相当のソフトウェアを使うのかについて。紙の手帳がなじむという人もたくさんいますが、わたしは手帳を自分の手元にいつでも開けるように持っているのがめんどくさいのと、自分の字が汚くて後から解読できないので、紙による管理は最初から候補から外れていました。 ではどんなソフトウェアを使っているかというと、Google CalendarとGoogle Todoリストの二つです。これらに素晴らしい機能があるから使っているわけではなくて、目の前にあって必要十分な機能を備え

    タスク管理、スケジュール管理方法の共有 - 覚書
  • 休みの日は休めばいい - 覚書

    以下の記事にマージしました。 satoru-takeuchi.hatenablog.com 昔この記事を書いたのを忘れて似たような記事を書いたのと、両者とも似たようなことを書きつつ違うことも言っていたのがその理由です。

    休みの日は休めばいい - 覚書
  • ソフトウェア技術者はなるべくソフトウェア技術で目立つほうがいい 2 - 覚書

    ↓の続きです。 satoru-takeuchi.hatenablog.com 何をするにも知名度の有無によって注目度は変わります。極端な話をすると、誰かがものすごいことを成し遂げたとしても、誰とも接点が無い人がやれば誰にも知られず、すでに名のある人がやれば注目されます。なので知名度があればそれだけでいいか…というとそうではないです。 知名度の高まりかたにはいろいろと種類があります。そのうち一つは名声を博することです。名声を博するには技術者としてのスキルや地道な実績の積み重ね、場合によっては自己プロデュース能力が必要です。とてつもなく凄いが目立つのを嫌う人もいるので一概に知名度があればいいというものではないですが、その話はここでは置いておきます。 その一方で、人から眉をひそめられるようなことをすると悪名がとどろきます。これには別に技術者としてのスキルは必要ないので名声を博するよりも簡単です。

    ソフトウェア技術者はなるべくソフトウェア技術で目立つほうがいい 2 - 覚書
  • 性能と性能測定の基礎 - 覚書

    はじめに コンピュータの世界では「性能」および「性能測定」という言葉があります。これらの言葉にはたくさんの意味があるのですが、業務システムの構築、運用にかかわったような人でなければ、「PCの新しいパーツに対して様々なベンチマークソフトウェアを走らせること」が性能測定であり、その結果得られるものが「性能」といったところでしょう。記事ではそれ以外の、業務システムにおける性能や性能測定について述べます。 性能 ひとくちに性能といっても、さまざまな指標があります。代表的なものは「スループット」、「IOPS」、そして「レイテンシ」です。これらについてストレージデバイスを例に説明します。 スループットは単位時間あたりにどれだけのデータを送受信できるかであり、XX MB/sやYY GB/sのようにあらわします。性能といって一番イメージしやすいのはこれでしょう。スループットが重要な意味をもつのは大きなデ

    性能と性能測定の基礎 - 覚書
  • emacsからvimへ移行することにした - 覚書

    テキストエディタを20年近く使ってきたemacsからvimに移行することにしました。移行しようと思った理由はいろいろあるのですが、「なんとなく」というのが一番近い気がします。あえて細かいところを挙げると次の通り。 vim流行ってるらしいので触ってみたくなった 普段使う道具を別のものにして脳に刺激を与えてみたくなった emacsには山ほどパッケージがあるのは知ってるが、大して使っていない。色々を読んで試してみたけれども、しっくりくるものはあまりなくて結局標準機能ばかり使っている。実際、ここ数年.emacsはほとんど変化していない 昔は「emacsはエディタではない、環境なのだ。すべてがemacsで完結するのがいいのだ」と思ってたけど、最近はもっとシンプルなものでもいいかも、と考えかたが変わってきた 上記のうち「それvimにしても問題は解決しないよ」という話もあるかもしれませんが、まあ、最初

    emacsからvimへ移行することにした - 覚書