茶道の哲学を読んでみた

最近、茶道の哲学を読んでみました。 ちゃんと考えたりすると、哲学的な、思想の話しにもなる内容でした。ただ、そこまでの専門性を求めて読んだわけでもないので、以下では綺麗にまとめたりはしてないです… きっかけ 大きな理由があったわけではないですが、五島美術館にも行ったこともあり、茶道に関して少し知見を広めようと思ったことがきっかけです。 茶道は禅の精神が大元にあることや、以下のような性格、また、一期一会といった比較的知られている熟語に関しても強い関係性があるとは知らなかったです。ただ、茶道の風貌を見ていると、禅のような質素さなんかはつながるものがあるのかなとは感じていました。(千利休とか、日本の歴史でよく学ぶ箇所ですね) 茶道文化の7つの性格 茶道文化には、大きくわけて以下の7つの側面があるらしいです。 不均斉 ものの整ったというような事の否定 簡素 端的で、直截で、簡潔 枯高 やわらかい豊満さよりも、痩せて勁い 自然 無念無想といったもの 幽玄 底の知れない無底の深さ、言語道断、心行所滅 脱俗 人も仏も否定するような、徹底した脱俗 静寂 物の無一物の静けさ いずれも、様々な箇所で禅や仏の話しが取り上げられていました。多くは通じるものがあるのですね。 そのほか気になった言葉 和敬清寂 茶道における”好み” 既成の物事の中から茶道の規範に合うものを択び採る 茶道の規範に合うものを新しく形成するとか、創造するとかいうこと 侘び 足るを知る 一期一会 道 海外の人と話したりするとき、日本の事を少し話せたり、比較的有名な茶道や禅に関して知見があると話しのきっかけにもなります。また、年齢が上の方と話すときも、多少の知見は役立ちます。あまり専門性を求めるわけではなく、少し教養程度にかじる程度ですが、こういう書籍を読むのも気晴らしになって面白いですね。 Zenとか、ソフトウェア界隈でも話を聞いたり海外の人が使ってたりします。が、私はZenに関して質素とか、簡潔とか、そういう薄っぺらい理解しかないので、禅なんかも今度は読んでみようと思っています。硬い文章ではなく、面白そうな書籍を見つけたので…. 量としては半日くらいかな。More

Exercism.ioでちょっとしたプログラミング問題を解いていく

最近、exercism.ioというプログラミングを学ぶサービスを使ってみています。 http://exercism.io 世界を相手に腕を磨けるプログラミング学習サイト「Exercism.io」のWIREDの記事に惹かれてやってみたのですが、なかなか面白いです。 これは、ちょっとした問題を順に解いていく、というものです。解いた回答はサイトにサブミットし、サブミットすれば次の問題を取得、解くことができる、というものです。サブミットした回答は様々な人が見ることができる状態になり、時折、気になった解答例や自分の解答にコメントしてくれる人もいます。 同じ解き方を、面白い方法で解いたコードはナルホド、と思うところがありますね。 問題の内容自体は、TDDのようにテストコードがあらかじめ用意されており、そのテストコードがすべてグリーンになるまでプログラムを構築して解いていく、というものです。中には素数判定が必要なものもあったりと、ちゃんと考えればより高速なアルゴリズムで問題を回答できるといった種類の問題も存在します。 ちょっとしたプログラミングを使ったクイズみたいな位置づけですね。他の人の回答みたりすると、自分とは異なる使い方や、よりスマートな記述で問題を解いているものもあって、程よい頭の体操になりそうです。 Code Schoolのようなちゃんとした学習をするサービスもありますが、ここは小さな問題がたくさん転がっているので、カジュアルに遊ぶことができるのが面白い。 2015/01/24 時点で、以下の言語の問題が用意されています。 私はRubyを少しやってみました。他のコードにも触れてみようかなと思ってます。More

MicroServices Patternを読んでみた

こちらの、パターン集を集めている?Webサイトに載っていたので読んでみました。 http://microservices.io/patterns/microservices.html Context and Problem レイヤー分けされたり、hexagonal architectureをもつアプリケーションは、以下のようなコンポーネントから構成される。 Presentation compornents Business logic Database access logic Application integration logic このような様々なレイヤー分けされたサービスから構成されるシステムを(ざっくりと)マイクロサービスと呼ぶ。 これらの構成をもつアプリにおけるデプロイアーキテクチャはどのようなものか? Solution Scale Cubeなアプリケーションアーキテクチャ 機能的に分解された多くのサービスの集合としてアプリケーションが動作する サービスは、HTTP/RESTのような同期的なコミュニケーションと、AMQPのような非同期的なコミュニケーションを使う サービスは、それぞれが独立して開発/デプロイされる それぞれのサービスは、それぞれが分離するために自身のDBをもつ。それらのDBはレプリケーションやアプリケーションレベルのイベントで保守される。 Solutionの問題 開発者は、モノリシックアーキテクチャ以上の、分散システムを構築するための複雑性を扱わなければいけない IDEやツールの多くは、モノリシックアーキテクチャ向けのもの Testingがより困難になる サービス間の内部処理の実装が必要 それぞれの開発チーム間の連携を構築する必要がある 分散トランザクションを使う必要が有る デプロイが複雑 個々のサービスが独立して起動、利用可能になるまでの時間が必要なので、サービスが利用可能になるまでに最大でサービス分のオーバーヘッドがかかる 類似 API Gateway pattern APIを受け取るgatewayを境界に、Client/Serverで扱う処理を分散させる Netflix APIのようなもの Scale Cube The Art of Scalabilityに記載されているパターン アプリケーションのスケールを、箱型のXYZ軸のそれぞれの軸をもとに表現して説明したパターン X軸スケーリング Horizontal duplication アプリケーションのクローンを増やすことでスケールさせる Y軸スケーリング Functional…More

基礎教養的な、組込みソフトウェア工学ハンドブックを読んだ

組込みソフトウェア工学ハンドブックを読みました。 組み込みソフトウェアと書かれていますが、組み込みに特化した話ではないです。 ソフトウェアに関わる歴史が、自動車産業から発展してきたことは有名なことでしょう。その流れからソフトウェア工学に関する話を全体的に書いているため、このタイトルになったのだと思います。 この著者に私は大学、大学院と学びました。ここに記載されていることは私が5,6年前の学部時代に学んだことの多くで、こういう話をよく聞いたな、と懐かしくもなりました。 内容は、 ・ソフトウェアの歴史 ・ソフトウェア開発の流れ ・ソフトウェア工学の基礎 ・ソフトウェアの品質 ・ソフトウェアレビュー ・ソフトウェアテスト ・ソフトウェアのメトリクスと品質管理 といった内容です。 いずれも、詳細な技術というよりは、抽象的な内容と簡易な例でまとめられています。少し、ソフトウェアの歴史から見たソフトウェアの品質・テストの流れを知りたいという人にちょうど良いかもしれません。ソフトウェアメトリクスの内容に関しては、数学的な言及もあるので面白いと思います。More

「イシューからはじめよ」を読んだ

イシューからはじめよ ― 知的生産の「シンプルな本質」 [Kindle版]を読んだ ある方からオススメされたので読んでみた。 知的労働者として価値のある仕事を行うために行う問題解決の一連の流れを載せている。問題(issue)の見つけ方、仮説、ストーリー、アプトプットへの変換など。私の読んだことのある問題解決系の本などにくらべて、技法のような話よりも”アウトプット”として誰かに共有、報告するまで全体を書いているところが価値のあるところだと思う。 知れば知るほど知恵が湧くより、知り過ぎるとバカになる という言葉が出てくるが、大学時代の教授の言葉を思い出した。書籍などに載っている既存知識を吸収することは大事だが、一定の基礎を学んだ以降は読みすぎないほうが良い。すでに存在する発想にとらわれ、自分で考えた自分の発想を大きく阻害するから、というものだ。 カナヅチを持っていればすべてのものがクギに見える という、マズローの有名な言葉にもあるように。 メッセージに納得して、行動に移してもらう。いくつかアウトプットの目的をあげていたが、私が常に意識しなければいけないアウトプットの目的が見事にこれだった。最近、外部で発表する機会も増えてきて、資料を作ることがある。その中で、ここでも書かれているようなストーリー性であったり、伝えたいことを絞れなどはよく言われているので、書籍としてまとめて読むことができることは、私には価値があった。頭に常に入れておきたい。 書籍のはじめに、「悩む」と「考える」という2つの言葉を、答えの有無で説明している箇所があった。私の思っていたことに似ていて共感を持てた。答えを見つけるために「考える」のと、答えを見つけるわけでもなく、思考を発散させたり単に思考を巡らせるだけの「悩む」。仕事を行う上での価値の有無は書籍に任せるとして、私はどちらも人なので必要だなと感じた。 何か課題を見つけ、考え、アウトプットへ落とし込む方法をざっと頭に入れておきたい人にはオススメの本。細かな技法を知りたいという人には、他を当たった方が良さそうな内容。 自己啓発とか、課題解決の思考云々の書籍はあまり読まないが、これは文章や発表資料を作成するときは時折読みたいと感じた書籍だった。More

WACATE 2014 冬に参加してきた

最近常々思うのですが、テストエンジニアも役割が細分化されて、役割が再定義される時代がすぐそこそうですね。開発者が、xxx(特定の言語)エンジニア、サービス開発エンジニア、インフラエンジニアなどのように区分して呼ばれるように。例えば、最近、テスト自動化エンジニアと呼ばれる人たちが出てきましたが、それもその一つだと思います。 さて、話題は変わり、12/6、12/7の2日間で開催されたWACATE 2014 冬に参加してきたのでその話をまとめます。1ヶ月くらい経ちましたが、ようやっとブログポストになります。。。Twitterにおけるハッシュタグは #wacate だそうです。 WACATEとは WACATEは「Workshop for Accelerating CApable Testing Engineers」の略で、「内に秘めた可能性を持つテストエンジニアたちを加速させるためのワークショップ」という意味です。 前々から日程が合えば参加してみたいと思っていたのですが、日程が合わず今回初参加。初参加ながらも、分科会をさせていただきました。 ここでふと疑問に思うのが、若手の定義です。こちらのCIAの資料によると、日本の平均年齢は46.1歳のようです。そこから考えると、30代までが若者といっても良さそうな範囲ですね。 なお、WACATEとはによると 35歳以下 だそうです。More

3年間半くらいで読んだ技術書まとめ

社会人になって、4年目も終わるころです。 新人として働き始めたころから、学んできたソフトウェアテストの話、開発の話なんかで、書籍として読んでいたものを少し列挙しようと思います。2011年~2014年終わりの間に書籍として読んだものが中心です。 最近、外で会話するようになって、何を読んだかとか知っておくと良いかなと感じたので。なお、中身に関しておろ覚えのものも多いですが、これらの書籍は基本的には必要に応じて読んでいる感じです。専門であるソフトウェアテスト関連は適宜読みつつ、実践できそうなものは実践しています。 他にWebページベースやWeb+DB PRESS、Software Designなどいろいろ読んでいるのですが、ここでは省きます。More

ソフトウェアテストあどべんとかれんだー2014の13日目の記事を書きました

モバイルアプリのリリースサイクル毎で行っているテストの流れということで、ソフトウェアテストあどべんとかれんだー2014 の話を載せました。 WordPressの他、Qiita、Hatenaと書いてみたのですが、個人的にWordPressで十分そう。 あと、以前少し試しただけの https://medium.com/ ですが、こちらにもいつかポストしてためしてみよう。More