個人的なメモの色々(scrapbox､trello、hugo､Googleカレンダー、mattn/memo) 最近いろんなドキュメントというかメモというか。雑文の置き場所を考えている。 trello scrapbox hugo(github.io) Googleカレンダー mattn/memo などに最近は落ち着いてきたかなと思う。 なんでこんな色々つかってんの？っていう自分なりの理由についてのお話です！ どこに公開して誰に見せるか見せないか このブログの内容も大体雑多なものなんだけど、 一応このブログに書くならこういう書き方、こういう内容みたいなものが自分にはある。 なので、全て日常なりなんなりをこのブログにだけに書くわけにもいかない。 そういった中「書きたい内容ごとにツールを分ける」必要性を感じてきた。 そこで、今回は何をどういう意図で使っているかを書いてみます。 trello ここ数

なんとなく書いてみた。というか書いてみると作業方針ぽくなったし、チケットの捌き方みたいになった。 IDEを駆使して自分の作業をoptimizeする ショートカットキーとコード補完などは覚える。 操作を行う頻度の多いもの、処理に時間がかかっているものを最適化するのが目的。 IDE自体の処理スピードがネックになる場合はチューニングすること。 タイピングからのレスポンシビリティが下がる、 ビルド・デプロイにコードベースの量から想定される以上に時間がかかる。 などと行った場合はなんらかのゾンビプロセスなりが存在しているかもしれない。 なるべくチケット化する これはプロジェクト方針と合致するかということも大いにあるけど、 基本的にチケットは細かくあったほうが良いと考える。 明らかに作業に対してチケットのタイトルが合致していない場合、 チケットにない作業をしている場合などが該当する。 タスクを細かく切

主語がでかいタイトルですが、自分なりに考えようという目的です。 自分の思考の整理。 何か意見があればガンガンコメントなりツイートなりして欲しい。 前提として、 チケット管理システムは２つぐらいしか使ったことがないので、そちらに偏ってしまうかも。 ちなみにRedmineとBacklog。 （今がRedmineだから多分それに偏る気が） アンチパターン アンチパターンというのかは分からないけど 今まで困ったこと、やりにくいと感じたこと、ダメだこりゃ、と思ったこと。 ・運用フローが複雑 フローが複雑だと途端に人は面倒になる。なるべく抜け道を探し秩序が乱れる。 抜け道が見つかると割れ窓理論とかいうやつで、どんどんぐちゃぐちゃになる。 誰もフローに乗ってくれない状態になる。 ・使われていない項目がある なぜあるのかわからない項目。重要そうだけど埋めなくても良い項目。 誰かが埋めてくれるだろう、他の人

はじめに 技術を学ぶというのはすごい個人差のあることだと思います。 個人特性もあるし、興味の向く対象も違う。 組織にはいろんな人間がいる。 そんな中、いくら「技術力を学ぼう！」と啓蒙しても、 響かないことってありませんか。 最終的には人それぞれの問題にはなってくるのだけれど、 それって、現場ロックインが一因なのではないかなと思う。 現場ロックインの定義 「特定ベンダー（メーカー）の独自技術に大きく依存した製品、サービス、システム等を採用した際に、他ベンダーの提供する同種の製品、サービス、システム等への乗り換えが困難になる現象」をベンダーロックインという。 (Wikipediaより引用) 現場ロックインは僕の思いついた単なる造語で、 「特定のプロジェクトに特化した技術や顧客の事情を重視しており、 その他の現場に移動しても殆ど役に立たないローカルルールに依存している現象」を指す。 会社に対して

‌ という完全に仮説というか思考実験みたいなものを書いてみます。 ざっくりまとめ ベテランの何気ない情報は世に出にくいという仮設 ベテランは、独自見解など良い感じのもの以外の簡単な技術記事が書けなくなる、書きにくくなる 簡単な記事は経験浅めの人に偏りベテランは簡単な記事を書かない。簡単なものでも書いてくれるベテランは、アウトプット好きに限られる 簡単なものであったとしても世に出してくれれば嬉しいな 前提 経験の浅い人 = 初級者 ベテラン = 中級者以上 とおきかえてもらっても良いかもしれません。 経験の浅い人は簡単なことでも感動できるのでブログを抵抗なく書きやすい 例えば 「Javaのセットアップが出来た！」 「Rubyのセットアップが出来た！」 「このライブラリで良い感じに出来た！」 はじめのうちは一つ一つが嬉しいし一つ一つにハマりがちだったりするので、 感動もありハマりどころもありブ

すでに何人かの人がクリーンアーキテクチャなんてないよ、って話はしていてイマサラだと思うんですが。 あえてブログの記事に残そうかなと思って書いてみます。 最近、改めてクリーンアーキテクチャ本を読んだり、原文を読んだり、 ここ数ヶ月ツイート色々な人のを観測したり社内で話したりしていて 考えがまとまってきたので、自分の言葉で整理してみたくなった。 「へー、クリーンアーキテクチャっていうソフトウェアアーキテクチャがあるんだー」という微妙な誤解？をちょっとでも減らす一助になればという感じです。あと、本の読み進め方のヒントにもなるかも 先に結論 クリーンアーキテクチャというのはアンクルボブの書いた本。 ソフトウェアアーキテクチャのことではない。 the クリーンアーキテクチャというブログ記事はただのソフトウェアアーキテクチャの例(そして本の一部分)だが、独り歩きしている クリーンアーキテクチャというソ