『学びの構造』を読んで、自分の学び方や、他人の学び方を見直そう - Magnolia Tech
「学び」の構造 作者:佐伯 胖東洋館出版社Amazon TwitterのTLで見かけた、佐伯 胖さんの書かれた『学びの構造』という本が気になって読んでみた。 昭和50年に発行されて、今年になっても増刷されている歴史ある1冊。 元々、学校教育の現場の人向けに書かれている本みたいだけど、「学ぶことを指導する立場」の人であれば必ず刺さる内容ばかりだった。 特に第二章の”「おぼえる」ことと「わかる」こと”で語られている、「わかる」の定義は必読。 「わかる」とは「わからないところがわかる」ことだと定義し、そこから「わからない部分」に行き当たると「疑問がわき」、それが全体を統合する働きをする、という流れは非常に納得感が有った。 そう、確かに分かっていないと疑問にも思わないし、質問も出てこない。そして「分かった気になって」、やろうとしても実は理解していないから「手順通りのこと」はできても、その先ができな
『私たちはどう学んでいるのか: 創発から見る認知の変化』を読んで、勉強することへの取り組み方について考えたこと - Magnolia Tech
ときどき、TwitterのTLに流れてくる情報をもとに本を買うことがある。 買いました https://t.co/qNlBn756Hx— magnoliak🍧 (@magnolia_k_) 2022年8月18日 普段、読書といっても技術書や、好きな作家の小説に偏りがちなので、自分が自然に手に取らない本を読むためにも「教えてもらったものを、とりあえず”買って”読んでみる」という方法は有効だと思っている。 私たちはどう学んでいるのか ――創発から見る認知の変化 (ちくまプリマー新書) 作者:鈴木宏昭筑摩書房Amazon 今回それで知って、読んで面白かったのが、この『私たちはどう学んでいるのか: 創発から見る認知の変化』。 ソフトウェアエンジニア界隈でよく議論になる「エンジニアは土日も自主的に学習すべきか」という話題が有って、その是非はここでは触れないけど、”そもそも学習ってどうすれば効果的な
書かれて、レビューされて、合意されたものが”決まったこと” - Magnolia Tech
これ超大事 単にペラペラ喋っても、それはレビューできないんだよ 喋ってることってまとまっていないから ディスカッションはいいんだけどね ただ言っただけのことを「決め事」にするのはとても危険 https://t.co/DzASlZNqqs— magnoliak🍧 (@magnolia_k_) 2022年3月5日 「書かれて、レビューを受けて、合意されたものだけが決定事項だ」って言われた— magnoliak🍧 (@magnolia_k_) 2022年3月5日 「○○さんが言ってました」では決定事項であることの証跡にならないって— magnoliak🍧 (@magnolia_k_) 2022年3月5日 何を持って「決まったこと」とするか、その定義があいまいなまま進めると当たり前だけどロクなことが無い。 「仕様は○○です」と言っても、実はたまたま誰かが「こうしようかな」と呟いただけのことだ
『ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ』を読めばアーキテクトになれるのだろうか - Magnolia Tech
ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ 作者:Mark Richards,Neal FordオライリージャパンAmazon とても良い本だ！アーキテクチャのパターンは体系的に整理されているし、アーキテクチャを議論する上で、共通の語彙となり得る用語を解説している（コンウェイの法則や、凝集度など）。 後半は、リスクや、チームビルディング、交渉術まで多岐に渡るトピックを網羅している。 必要なことは全部書いてある...けれど、なんとなく初めてPMBOKを読んだときに抱いた感想...読み始めてからすぐに「果たしてこの本に書かれている通りの考え方に沿って振る舞えばアーキテクトになれるのか？」という気持ちになりはじめたところで1章の最後の方に出てくる「ソフトウェアアーキテクチャの法則」が出てきて、「そうだよなー」という気持ちに。 ソフトウェアアーキテクチャはトレード
「ドメイン駆動設計」を読んだ〜第1章 知識をかみ砕く〜 - Magnolia Tech
引き続き「ドメイン駆動設計」を読み進めました。 「第1章 知識をかみ砕く」には、ドメインエキスパートと、開発者の会話を通じてモデルを作り上げていく様子から始まります。 モデルを書いて可視化すること 繰り返し相互のフィードバックでモデルを成長させること モデルと実装(プロトタイプ)を結びつけて、早期のフィードバックを得ることの重要性 新しい概念を新しいモデルの要素として、抽出・分離すること といったことが書かれています。 モデル化そのもののテクニックの詳細は書かれていませんが、最初から全ての要素を全て揃えて完全なモデルを書くのではなく、その時点で関心を持っていること（つまり、ドメイン）に集中してモデル化し、(画面等も無いミニマムな)プロトタイピングによりその本質を捉えていることの検証とフィードバックを繰り返しているところが特徴です。 途中、ウォーターフォールにはフィードバックが欠けているため
設計書には何が書かれてるべきか - Magnolia Tech
Noteからの転載 —- 設計書は、現在、または過去、未来をつなぐコミュニケーションツールなので、そのコミュニケーション設計をどうするか？って話を抜きに、どう書くべきか？そもそも書くべきか？みたいな議論を始めてしまうと、会話が成立しないことが多いですよね 必要な抽象度だって全然違ってくるし— magnoliak🍧 (@magnolia_k_) 2021年2月6日 これが設計書です！と言われて見せられたものが、あからさまに個人的なメモを超えるものでない場合、「この文書は誰とのコミュニケーションを目的としましたか？」と聞くと良いのではないかっていう みんなオレオレ正しい設計書理論があるので— magnoliak🍧 (@magnolia_k_) 2021年2月6日 設計書になにが書かれているべきか、コードの世界と違ってあまりコンセンサスが得られた回答を見たことが無い気がする。 かなり大きめの
「Design It!」を読んだ - Magnolia Tech
副題にある通り「プログラマのためのアーキテクティング入門」ということで、どうやってシステムのアーキテクチャを設計していくか？という課題に対して向き合うための方法を示してくれる本です。 とはいえ、所謂アーキテクチャカタログ集ではないので、即効性の有る内容ではなく、ゼロベースでアーキテクチャを決めていくための思考のステップを示してくれる内容なので、具体的なアーキテクチャにつながる技術要素は、ここに示された内容を元に情報収集し、判断し、決めていくしかないですね。 第Ⅰ部 ソフトウェアアーキテクチャ入門 1章 ソフトウェアアーキテクトになる 2章 デザイン思考の基礎 第Ⅱ部 アーキテクチャ設計の基礎 3章 デザイン戦略を立てる 4章 ステークホルダーに共感する 5章 アーキテクチャ上重要な要求を掘り下げる 6章 アーキテクチャを選ぶ（君がアーキテクチャに選ばれる前に） 7章 パターンで土台を作る
設計がいつも可視化されているとは、限らない - Magnolia Tech
"意識的に意思決定されたことでなくても、そこに設計が有るんだ、暗黙知として。" 結果的に、たまたまできあがった、明文化されていない仕様は仕様と言えるのか、それは設計と言えるのか、と言えるけど、それがユーザーに見えている挙動である以上は仕様であり、設計なんだ。 でもそれがいつも可視化されているとは限らず、たまたま言われたら、確かにそうかもという話になってしまうんだけど、案外そういうところに大事な要素が詰まっている。
駆け出す前に『コーディングを支える技術』を読んでみるのはどうか - Magnolia Tech
コーディングを支える技術――成り立ちから学ぶプログラミング作法 WEB+DB PRESS plus 作者:西尾 泰和発売日: 2018/11/14メディア: Kindle版 よく初心者向けの定番書籍として『リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)』の名前が上がるけど、『コーディングを支える技術』もなるべく早い時期に読むことをお勧めする1冊だと思う。 この本の冒頭で、技術の学び方には、以下の3つがあると説明している。 比較から学ぶ 歴史から学ぶ 作ることで学ぶ 「作ることで学ぶ」系の本も非常に有効だけど、この本は筆者は「比較から学ぶ」「歴史から学ぶ」に多くページを割いていると書いている。 そう、いろいろな言語を複数比較しながら解説が進むところが良いのだ。現代では、ただ一つの言語だけですべて賄える、という訳にはいかず、
一冊の本をじっくり読み込み、知識を吸収するためにはどうすればいいのか - Magnolia Tech
blog.shibayu36.org 先日、id:shiba_yu36さんのブログで、同じジャンルの本を複数同時並行で読み、気になったキーワードを繰り返し選別していって、読書ノートにまとめることで知識の吸収速度を上げる、という内容のエントリが話題になっていた。 確かに同時並行で同じジャンルの本を読むことで、同じキーワードでも複数の視点で考えるきっかけになって、より理解し易いという効果が有ると思う。一方で、自分は元々一冊の本をじっくり最後まで読み切るのが苦手で、だんだんと読み方が雑になって、後半は流し読みくらいになってしまうことがよく有る。 では、どうすれば1冊の方をじっくり読み切って、かつ知識を吸収することができるか、ということを考えてみた。 「目次」と、「はじめに」をじっくり読む 前半部分は並列に読む 中盤まで行ったら最初に戻る メモできる環境を用意する 分からないキーワードは都度調べる
どうやってコーディングを学ぶか - Magnolia Tech
CPANに上がってるモジュール、一つ一つの粒度が小さいから読みやすいし、ドキュメントもテストもしっかり揃ってて挙動を把握しやすくて、自分にとっては最高の教科書だったな 今でも他の言語で分からない時に同じ目的のPerlモジュールを見る事があるし— magnoliak🍧 (@magnolia_k_) 2021年1月7日 自分が学んだ頃の、時代的なものもあるけど、今でもPerlのモジュールは粒度が小さく、ドキュメント、テストがしっかり用意されているので、参考にするにはちょうど良いと思っている。 ScalaのScalatraっていうWAFのメンテナンスに参加しているんだけど、HTTPプロトコルだったり、Webのお作法的なところが分からないことが有ったら、たいていPlackか、Rackのソースを見て理解するところから始める、みたいなことしてる— magnoliak🍧 (@magnolia_k_)
「リファクタリング第2版」を読んだ - Magnolia Tech
リファクタリング(第2版): 既存のコードを安全に改善する (OBJECT TECHNOLOGY SERIES) 作者:Martin Fowler出版社/メーカー: オーム社発売日: 2019/12/01メディア: 単行本 初版、たぶん読んだはずだけど、全然覚えていないので第2版を購入。JavaScriptには慣れていないけど、特に読む上で支障は無かったです。 かなり分厚い本なので、最初から読むとけっこう挫折してしまうかも…特に大部分はリファクタリング作業のカタログ集なので、頭から読むにはちょっと適していない構成です。 ある程度リファクタリング的な作業を経験した人であれば過去にやったことの有る作業を拾い上げて、自分の暗黙知を形式知にしていく読み方がお勧めですね。 まだリファクタリングを経験したことが無い人だったら、迷わず第10章から読むことをお勧めします。複雑で難解なコードは、複雑な条件式
属人性をどう捉えるか？ - Magnolia Tech
「職場の属人性を排除して、誰でも同じ作業ができるようにしよう」みたいな話、よく話題になる。 でも、そのタスクのフェーズによって「属人性」が表す意味は変わってくる。 すべての新しいこと・ステキなことは、ひとりの人間の脳内の、まさに属人的な、思いと欲望と発想から生まれるのですよ。— 杉本啓 (@sugimoto_kei) 2021年1月16日 ダメな属人化、というのも確かにある。協力会社さんから受け取った請求書をどこにしまってあるか、担当者以外はわからない、みたいな。— 杉本啓 (@sugimoto_kei) 2021年1月16日 属人性の排除というより、後世の人のために、畦道を舗装して、より早く走れるようにする、という表現がいいよね— magnoliak🍧 (@magnolia_k_) 2021年1月16日 どうしても、その一番の人は、いつかはいなくなっちゃうし、いなくなったことで、止まっ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
成長は経験の質の掛け算じゃないかって考えた - Magnolia Tech