長い期間、継続的にブログを書き続けるための工夫 - $shibayu36->blog;
10年前からブログを始めて、10年間コツコツコツコツ学んだことや考えたことを記事として書き続けてきた。その結果、ついにブログの記事総数が1000記事近くになってきた。10年間かなり頑張ってきたなあと感慨深い。ありがたいことに読者数も1000人ほどいて色んな人に見てもらえるようになり、これも継続的に書き続けたおかげだなあと思う。 また、ずっとブログを書き続けてきたことで、以下のような多くのメリットを受けることができた。 ブログを書くこと自体が自分の頭の整理に繋がる その後知識を忘れたとしても、ブログを見返せば思い出せる 初めからブログに書くつもりで勉強すると、勉強の効率が上がる 反対意見とかツッコミを入れてくれる人が出てきて、自分の思い違いを正したり、より考えを洗練させることができる 記事を書き続けていると意外と読者が増えていて、気合を入れた記事を書いた時もみんなに見てもらえる 完全公開の場
ちょっとしたことでも雑にブログに書いておくと良いことが起こる - $shibayu36->blog;
僕は自分がやったこと・勉強したこと・気づいたことなどはどんなにちょっとしたことでも、公開の場のブログに書くようにしている。その内容はある程度雑でも良いので、とにかく公開の場に書くようにしている。それによって、結構良いことが起こっているというのを社内の日記に書いていたのだけど、これも公開の場に書いておいても良いかと思ったので書く。 これまでの経験だと、次のような良いことが起こっている。 最低限未来の自分に理解できる程度まで記事にまとめることで、知識が頭の中で言語化され、定着する 時々他の人からフィードバックを受けて、さらに学習が進むことがある 「あれ昔なんか勉強したけど覚えてないな」という時に自分のブログ見たらすぐ思い出す 分からないことを調べようとググったら自分のブログが出てきてすぐ思い出す 初めからブログに書くつもりでインプットすると、自然と体系化・汎化しながらインプットできるようになる
チーム内プロジェクトが発足した時に、プロジェクトの朝会を用意すべきか - $shibayu36->blog;
最近チーム内で少し大きめなプロジェクトが発足して取り組んでいたのだが、その時プロジェクトの朝会(デイリースクラム)をするべきなのか悩んだことがあった。自分の中ではプロジェクトごとの朝会を用意すべきという結論に至ったのだが、今回はその結論に至った経緯をメモしておく。 なおこのような開発フローの話は全てのチームに適用できるわけではなく、チームの状況によって最適なものが違うので、一つの参考例としてどうぞ。 前提 7~8人ほどのチームで、3~4人で取り組むプロジェクトが発足したときの話 チーム全体の朝会は行っていて、進捗確認や問題解決はそこそこ上手く行っていた チームの朝会は、一人ずつやったこと・やること・気になりごと・相談を発表するスタイル プロジェクト朝会実施前 最初は全体朝会で話せば良いかと思い、プロジェクトの朝会は用意していなかった。しかし、最初は良かったものの、徐々に問題が起き始めた。例
アイスランド旅行記 - 町並み編 - $shibayu36->blog;
blog.shibayu36.org 前回の記事で特に自然を紹介したのだけど、アイスランドの首都のレイキャビクについてはあまり触れなかった。しかし、レイキャビクの街は非常におしゃれで、自然風景とはまた別の楽しさがあった。何日も滞在していると、日本に帰った時に一瞬なんでこんな街がださいんだろ、と思ってしまうほどだった。 というわけで、今回は町並みを中心に紹介をしようと思う。 アイスランドはとにかくカラフルな街だった。家が様々な色で塗られていて、しかしそのようなばらばらな色を使っていても、全体としては調和が取れているように感じた。 これが全体の町並み。 また、建物にいろいろな絵が描かれているのも印象的だった。ちゃんとデザインされたものが多かったので、これは仕事として誰かがやっているのだろうか？ 他にもちょっとした建物やオブジェクトがおしゃれなものが多く感じた。 ちょっとしたアイコンもかわいい。
JavaScriptのPromiseの概念について学習した時に参考にしたもの - $shibayu36->blog;
JavaScriptのPromiseを使った実装をコードレビューしていたのだけど、やってみたら自分があんまりPromiseについて理解できていなかったことに気づいた。特にこれまでjQueryのajaxやjQuery Deferredをなんとなく使っていたのだが、Promiseの根本的な概念がjQueryの巨大な仕様の中に埋もれていて、自分の中でjQueryの機能とPromiseの概念を分離して正しく言語化出来ていなかった。 そこでPromiseの根本的な概念を再学習したので、何を参考に勉強したかを書いておく。 PromiseについてはとにかくJavaScript Promiseの本を読めば大体把握できる。このドキュメントを読めば Promiseの概念 ES6 Promiseの利用方法 Deferredとの関係性 などといったことを知ることができる。 個人的には次の部分が特に参考になった。
ElasticsearchのAnalyzerを理解するため全文検索の仕組みをシンプルに考える - $shibayu36->blog;
Elasticsearchを使おうとしているとAnalyzerという概念が出てくるが、このAnalyzerという概念は最初理解することが難しかった。全文検索の仕組みを理解すれば分かるだろうと思い、https://speakerdeck.com/johtani/elasticsearchru-men?slide=5 やhttp://www.atmarkit.co.jp/ait/articles/1111/18/news148.html の記事などを読んで勉強してみたものの、こちらもいろんな言葉が出てきて非常に混乱した。例えば転置インデックス、tf-idf、トークナイズ、ストップワード、N-Gram、正規化などといった言葉が出てくる。 いろいろ調べてみて整理すると、全文検索の技術には、なぜ検索ができるかの話以外に、類似度の話、検索を高速に行うための話、あいまいな検索に対応する話など、いろんな話
仕様や実装方針の相談をPullRequestで行う取り組み - $shibayu36->blog;
これまで少し大きめな機能であれば、コードを書く前にまず仕様や実装の方針をissueのdescriptionにまとめ、それを先にレビューしてもらってから実装にとりかかるということをしていた。最近、その方針をそもそもrepositoryのファイルとして書いて、PullRequestしてレビューしてもらうようにしたら便利だったのでご紹介。 なぜコードを書く前に仕様や実装の方針をレビューするのか 前提としてなぜコードを書く前に仕様や実装の方針をレビューして欲しいのかについて書いておく。これはとにかく手戻りの量を少なくしたいという要求のためである。 実装に取り掛かろうとすると、実装の方針はいくつか思いつくが、どれが一番よいか迷うことはよくある。その場合に誰にも相談せず自分だけで判断し、コードを書いてからPullRequestを送った場合、もしその選択に重大なミスがあった場合全て書きなおさないといけな
良い物件ではなく良い不動産屋を探した - $shibayu36->blog;
いろいろあって今の家から引っ越すことになった。 良い物件どうやって探したらいいか分からなかったので、適当にググって http://nanapi.jp/286/ を実践してみたら、結果的にうまく行ったので経験をメモ。 結論 良い物件を探すのではなく、良い不動産屋を探すという方法にしたところ、僕の性格としては上手く行った 今回の流れ suumoやhomesで住みたい場所の物件を眺める 希望条件をまとめる 不動産屋を選んでメールしまくる 良さげなところを数社に絞って、さらに送られた物件見ながら返信してみる 一番いい感じに返答してくれた雰囲気の店に行って相談 suumoやhomesで住みたい場所の物件を眺める http://nanapi.jp/286/ とやってることは一緒なので割愛 希望条件をまとめる http://nanapi.jp/286/ とやってることは一緒なので割愛 不動産屋を選んでメ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
