技術的負債のパターンと悪影響・原因・返却方法について考える - $shibayu36->blog;
先日飲み会で技術的負債についての雑談をしていた。結構いろいろな側面の話をしていたのだけど、技術的負債って一括りにしているのが今はあんまり良くなくて、負債の性質によって技術的奨学金、技術的FX、技術的年金などと言葉を変えると良いのではみたいな半分冗談で会話をしていた。 いろんな問題が技術的負債という一言にまとめられてしまっているので、負債の性質に合わせて、技術的奨学金、技術的FX、技術的年金、など用語を分けると良いのではないか、という話をした— 趣味はマリンスポーツです (@hitode909) 2018年3月27日 技術的負債について - hitode909の日記 それで技術的負債のパターンを見つけて、それによりどういう悪影響があるか、それがなぜ起こるのか、どう返却するかについて考えておくと良いのではと思ったので、今日思いついた3つのパターンをメモしておく。 思いついたパターンは3つ。 変
ioドメイン障害を理解するため、DNSの仕組みについて勉強した - $shibayu36->blog;
先日、ioドメインの障害があったのだけど、自分がDNSの仕組みをよく分かっていないせいで、いまいちどういうことが起こっていたのか把握できなかった。そこで、DNSの仕組みについて軽く勉強したので、そのメモを残しておく。内容は間違っているかもしれないので、その場合は指摘してください。 DNSについて学んだこと Software Design 2015/4のDNSの教科書が非常に勉強になった。また、 インターネット10分講座：DNSキャッシュ - JPNICも参考になる。 権威サーバとフルリゾルバ まず、DNSサーバには権威サーバとフルリゾルバの二つの種類が存在する。 権威サーバ ドメインの情報を管理し、自分の管理しているゾーンの情報を提供するだけのサーバ 問い合わせたドメインが自分のゾーンの管理下ではない場合、別の権威サーバへ委任するという情報を返す コンテンツサーバとも言われる? 例) co
雑に書いたブログ記事が問題を起こさないようにする工夫 - $shibayu36->blog;
ちょっとしたことでも雑にブログに書いておくと良いことが起こる - $shibayu36->blog; で、ちょっとしたことでも雑にブログに書いておくと良いことが起こるよということを書いた。さらに余談として最低限の雑さについても書いた。 これをきっかけに、公開の場でアウトプットする時の最低限の雑さとはなんだろうという疑問が自分に生まれ、雑さによる問題や、それを引き起こさないようにするための自分の工夫について少し頭がまとまってきたので、自分の考えを書いておく。 過度な雑さから生じる最大の問題 まずあまりにも雑に公開の場に書いてしまった場合の最大の問題について考える。この時、一番起こってほしくない問題は、「読み手が誤った情報を正しい情報と信じてしまう」ことだと考えた。 あまりにも雑な文章は読み手の誤認を引き起こし、正しい情報ではないのに正しいと読み手が解釈してしまう問題がある。正しいと解釈してシ
ちょっとしたことでも雑にブログに書いておくと良いことが起こる - $shibayu36->blog;
僕は自分がやったこと・勉強したこと・気づいたことなどはどんなにちょっとしたことでも、公開の場のブログに書くようにしている。その内容はある程度雑でも良いので、とにかく公開の場に書くようにしている。それによって、結構良いことが起こっているというのを社内の日記に書いていたのだけど、これも公開の場に書いておいても良いかと思ったので書く。 これまでの経験だと、次のような良いことが起こっている。 最低限未来の自分に理解できる程度まで記事にまとめることで、知識が頭の中で言語化され、定着する 時々他の人からフィードバックを受けて、さらに学習が進むことがある 「あれ昔なんか勉強したけど覚えてないな」という時に自分のブログ見たらすぐ思い出す 分からないことを調べようとググったら自分のブログが出てきてすぐ思い出す 初めからブログに書くつもりでインプットすると、自然と体系化・汎化しながらインプットできるようになる
アイスランド旅行記 - $shibayu36->blog;
先日新婚旅行でアイスランドに1週間半ほど行ってきた。どうせならあまり行けないところにということでアイスランドにしたが、行ってみるとこれまで経験したことのない景色が広がっていて、本当に楽しかった。写真をいろいろ撮ったので簡単な旅行記を残しておきたいと思う。 到着〜ブルーラグーン 到着してすぐに全く違う景色が広がっていた。荒野のような雰囲気で、岩場に苔が生えている地帯がずっと続いていた。 最初にアイスランドの有名な観光地であるブルーラグーンに訪れた。ブルーラグーンはアイスランドで一番大きい温泉で、その名の通り非常に青い。 ブルーラグーンも青いが、その周辺ではおそらく鉱物の影響で全ての水が青くなっていた。水の青さによって空が水面に写っていて非常に綺麗だった。 今回泊まったホテルでは、そのホテルに泊まった人だけが入れる温泉であるシークレットラグーンというものがあった。ブルーラグーンよりも自然のまま
Scala入門してる - クラスとオブジェクト編 - $shibayu36->blog;
コップ本第04章を読んだ感想を少しだけ。 class クラス定義はclassというキーワードを使う。これで定義するのはインスタンスを生成するもの。ScalaではJavaのようなstaticなメソッドはclassでは定義できない。 varでpublicなメンバー、defでメソッドを定義。privateで隠蔽。 class Hoge { var a = 0 private var b = 0 def getB(): Unit = { return b } } object ではstaticなメソッドを作るにはどうするかというとobjectを使う。定義されたclassと同じ名前のobjectは同じファイルに記述する必要がある。なんの意味もないobject指定だけど、こういう感じ。 object Hoge { def piyo(): Unit = { println("piyo") } } まとめ
挫折しないための英語勉強 - $shibayu36->blog;
最近また英語の勉強をしている。僕自身は全く英語の勉強が続いたためしがなくて、毎回はじめてから1~2ヶ月くらいたつと英語の勉強に飽き、挫折してしまう。けれど今回は何とかして続けたいと思って、いつもとは全く違うアプローチで英語の勉強を続けたところ、今のところ6ヶ月くらい英語を続けられている。 今日はどんな感じで英語勉強してきたか軽く書いてみたい。 挫折しないために決めた方針 これまでは毎回英単語を勉強したり、英語の本を読んだり、英語のニュースを聞いてリスニングの勉強をしたり、といういわゆる英語の勉強をやってきた。でもこれだと自分は挫折するということが分かった。 今回は海外の人と友だちになれればモチベーション維持できるのではと考えて 海外の人と友だちになってチャットしたり会話したりを勉強の中心にする チャットや会話を円滑にするための勉強をする という方向性でやってみた。 効果的だったもの 効果的
github kaigi感想 - $shibayu36->blog;
github kaigiに参加して、発表したりとかした。発表内容についてはまた別で紹介するとして、感想だけ書く。 今回かなり印象に残ったのは「How GitHub Works」、「GitHubで 雑誌・書籍を作る」、「pplog.net の作り方( ˘ω˘) 」の三本。 「How GitHub Works」では、GitHubではどうやって良い仕事環境とかやりがいのある仕事を作っていっているか、みたいな話だった。その中でどうやってモチベーションを保ってもらうかみたいな話があって、外的要因と内的要因があって、給料とか設備とかの外的要因も大事だけど、それと同様に仕事の柔軟性とかやりがいみたいな内的要因も大事だよねと言っているのが面白かった。 柔軟性という話題でリモートワークについて触れていたけど、受けた印象として、やはりリモートワークを達成するために、リモートワークを潤滑にするための仕組みづくり
屋久島行った - $shibayu36->blog;
週末と有給使って、4日間屋久島行ってた。鹿児島はまだ行ったことなかったのと、屋久島なんとなくずっと行きたいと思ってたので良かった。 屋久島、空港が狭いのか、プロペラ機しか止まらないみたいな感じだった。空港もなんか降りた瞬間滑走路歩いてるみたいな感じで自由だった。 あと屋久島はとにかく自然が良くて、岩の島だから普通に本州で見れるような自然とは一風変わったものが見れた。雨がずっと降っているからか、苔もすごく多くて、あと木が絡み合ってる。 また動物も結構いて、そこら辺に鹿がたくさんいる。屋久島の鹿は人には慣れてるけど、奈良より図々しくない感じで良かった。屋久島は哺乳類が6~7種類しかいないし、人を襲うようなやつもいないらしい。 あとウミガメの産卵も見に行った。これは写真をとれなかったので残念。ウミガメとかはじめてみた。あとウミガメは光に敏感らしく、光はだいぶ制限されていて、その副作用で非常に暗い
開発フローに新しい仕組みを導入するとき気をつけていること - $shibayu36->blog;
最近開発フローに新しい仕組みを導入したりすることも多いのだけど、気をつけていることがいくつかある。 小さく導入する 短く導入する 振り返る 小さく導入する なんか導入する時は出来るだけ小さく導入してる。 理由は いきなりスクラムだとか言い始めてチーム全体のワークフローを変えようとした結果、チームの文化が崩壊する いきなりこれからはこのツールだとか言い始めてツールを導入した結果、誰も得してないのにツールだけ使われ続ける みたいなことがよく起こると思ってるため。既存の文化を壊したら元も子もないので結構気をつけてる。 小さく導入すれば、影響範囲を最小限に留めることができるし、あとから簡単にやめることが出来る。 小さく導入する方法はいくつかあって スクラムの中の一部だけ、チーム全体に適応する -> 導入するものを小さくする チーム内タスクの一部分だけに、仕組みを導入する -> 導入する範囲を小さく
職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;
Code Completeの上下巻を読んだ。 CODE COMPLETE 第2版 上 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazonCODE COMPLETE 第2版 下 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazon 読んだ感想としては、職業プログラマーなら必ず読むべき本だなと感じた。 この本ではソフトウェアコンストラクションに関する話題を扱っている。この本の中でソフトウェアコンストラクションとは、詳細設計、コーディングやデバッグ、単体テストなどなど、要求定義が終わった後、ソフトウェア製作に必要なプロセス全般のことを指している。 主なテーマとして、どうやってソフトウェアにおける複雑さを減らすことが出来るのか、について書かれている。そのテーマをいろいろな観点から説明されている。例えば以下の様な観点がある。 上流工程の欠陥による
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
