Some Days You Get the Bear

IT系エンジニアの、日々の気づきや考えたこと。

抽象 の検索結果:

ROS の説明 ~ALGYAN(あるじゃん)より~

…thon とかの言語レベルで、 ハードの制御を抽象化してくれてたりするのかなー? そういうハード割り込み使う部分は、マイコンでゴリゴリつくって それを ROS で組み合わせる(=ある程度、ハード側で自律)、って感じなのかなー? とか、まぁいろいろ勉強不足だな。 ただのメッセージングミドルウェア(メッセージ指向ミドルウェア )だと思うと、 ハード制御のしくみとしては、もの足りなさを感じる。 なんにせよ、これをきっかけに、もっと知っていこう。algyan.connpass.com

あとからわかる #EMFM

…冒頭からの、設計だ、抽象だ、という話がずっと続くんですが、 抽象構造があとからわかるか、はじめからわかっているか、 という話がすごくおもしろくって、 以下、広木さんのツイートを引用して、今日はおしまいとするのだ。 ソフトウェアのパラダイムとしてある抽象構造が、自明のものとして先験的に存在し、それを分析しながら、それらをツリーによって分類可能であろうとして、再利用可能なコンポーネントに設計するというOOP初期に描かれた継承による抽象の考え方を僕は、「オントロジー的抽象」と表現し…

コメントも「抽象度」なのだ

…いう情報。 "ひとつ抽象度の高い" 情報なのです。結局、コードだけだと、具体的な実装そのものしか見えなくて、 「そもそもの設計」が見えづらくなってしまう、それを補うためのコメントが欲しいのです。となると、抽象度を上げるということで、 やっぱり「意味のある部品」にして「読めばわかる名前」をつけておけば、 コメントなくても読めるじゃん、ということになるかと思うのです。 上記の Qiita をきっかけに、 コメントの書き方のことをググってみたら、けっこういろいろ書いてあったし。 Q…

『THE TEAM』と、サイコロで決めろって話

…わせた、目標設定(の抽象度)。 やっぱりチームメンバーの能力レベル、特に能力レベルの中でも『自ら考えて動く』ってレベルが高ければ、この抽象度の高い成果目標や意義目標を立たせて、自分でやらせた方が状況に合わせた動きが取れるんで成果出やすい。 一方で、自ら考えて動くレベルが低かったら、もう『これをやれば上手くいくからね』っていう行動目標までブレイクダウンしないと、どんどんずれた方向にいくんで、そこが一個見定めるポイントの一つですよね。 意思決定はスピードだいじ。納得感もそれなりに…

プログラム設計は「名前」と「場所」

…から。 プログラムは抽象化しているから「そのもの」ではないときがある。 そこのところの線引きが頭の中でうまくできないといけないし。 抽象化したもの/ことに対しても(別の)名前をつけないといけないし。 ちゃんとみんなにわかるように名前つけてあげないといけないし。 もうひとつは置き場所のこと。 この部品/この情報は、「どこ」に置いておくべきか、「どこ」に持たせておくべきか。 「持ち主」をはっきりさせることがだいじ。 もちろん、そこにはいろんなひとの考え方があって、 必ずしも満場一…

アウトプットのためのメモ

…素を抽出して学びを「抽象化」したものを右ページに書く。 さらに一番右に、ほかの企画や仕事に「転用」できないかと考えたことを書くんです。 ミーティングに出る理由って「新しい発想を知的生産するため」じゃないですか。 そう考えたら、この“右側”をアウトプットしないとあまり意味がないんです。 僕にとってメモは、アイデア創出のトリガーになる「宝の山」。 だから、1日に何回も見返すんですよ。 何が言いたいかというと、「フォーマットが知的生産を促す」っていうことなんです。 人間って空いてる…

スクラムは抽象クラス、というお話

…com Javaでは抽象クラスのインスタンスを作ることはできません。 これが意味するのは、抽象クラスはそのままの形では存在しえないということです。 派生させて、具体的な実装が行われれば、実体として存在できるようになります。 言い換えると、抽象クラスで規定されている振る舞いが気に入ったのであれば、そこから派生できるし、自分独自のバージョンを作れます。 しかし、そこには暗黙の契約もしくは了解があります。 抽象クラスを使うということは、そこで規定されている振る舞いを継承してそれに適…

章立ての「構成はストーリー」「階層は抽象化のレベル」なのだ ~仕様書の書き方(4)~

…く、はずだ。 何度か抽象化のことを書いているが、 設計って、抽象度の粗い/細かいをいったりきたりしながら 「俯瞰する視点」を変えてながら、ものごとを考えてまとめていく行為だと思う。 だから、仕様書にも、その観点が入っていてほしい、と思う。 大きな視点と小さな視点があるから、章立ては階層化される。 そう、「章立ての階層」は「抽象度のレベル」なのだ。 そういった構成の目を持つためにも、 技術書や論文のような「お堅い」文章にふれているほうがいいと思う。そうすることで、技術的な書きも…

「なぜそうなのか」が答えられるか

設計とは、 「なぜそうなのか」の理由付け・意味付けになるもの、だと思う。だから、自分のコードに対して 「なぜそうなのか」が答えられないようでは、プログラマとは言えないと思う。 そこに意思はあるのか?と思う。ただ単に動くものが作れるだけで、それでいいの?満足なの? てゆうか、設計とプログラミングって、切り離せることじゃないぢゃん! kuranuki.sonicgarden.jp プログラミングは製造ではなく、設計であるプログラミングとは、コンピュータにどのように動けば良いか指示…

気づく工程、考える工程

…を大量にしないので、抽象的な手順に留めておかなくてはならないからです。そして、ソフトウェア開発は「気づく」工程「考える」工程であり、気づくこと考えることのガイドはなかなか書きにくいからです。— Yasuharu NISHI (@YasuharuNishi) July 1, 2017 なるほどなー。 「ハードは手順の中に技術がある」ってのは、なるほどー、です。 ハードの仕事は詳しくは知らないので、間違ってるかもしれないけれど、ハード開発でも 設計は、エンジニアの知識や経験に依る…

適度な抽象度

…出会った言葉、適度な抽象度。「これだ!」と思ったね。いい言葉だと思った。抽象度のレベルや粒度を変えながらものごとをとらえて考えよう、と書いたけども、 これは、考えるのに適度な抽象度があるっていうことだね。カメラが、寄ったり引いたりするのと同じように、あるいは、虫めがねや望遠鏡があるように、 また、地図が、縮尺で詳しさや粗さを見せてくれるのと同じように、 そのとき見てる・考えてることに合った、ものの大きさや粗さがあるってことだ。こうやって、ソフトと思考はますます近くなっていく。…

関数のつくりかた

… システムの中の/世の中の「こと」「もの」をどう捉えてどう表すか、ということだ。処理の複雑さ・煩雑さや、量の多少ではなくて、 抽象度のレベルや粒度を変えながらものごとをとらえて考えよう、ということだ。大きくとらえて大筋をつかみ。小さな事象をその中に表現していく。 それは設計そのものだ。だから、プログラムは「ただなんとなく書く」ではなくて、 自ら能動的にシステムの世界(観)をつくるという意識でもって書き上げていかなければならないのだと思う。設計とプログラミングに境界はないのだ。

アジャイルはエンジニアの復権(ルネサンス)である

…。例えば、ものごとを抽象化し概念化できるからこそ、ソフトウェアが設計できるのだし、 コードを読んだときにも、コード側から設計意図を理解することができるのである。また、コードが書けるということは、無からモノを生み出す行為であるが、 無に形を与える力こそ設計力である。 設計に裏付けされていないコードなんて、カオスでありカス!である。 コードが書けるだけならば、エンジニアとして意味がない。だから、いつまでも偏った仕事ばかりしていてはいけないのである。そして、仕事は設計やコーディング…

まずは「箇条書き」でしょ! ~仕様書の書き方(2)~

仕様書の書き方、第2弾です。漏れ抜けのないようにと、あれもこれもと盛り込みたくて、 ついつい長文になってしまうこと、けっこう多いように感じています。しかし、仕様書は、まずは「箇条書き」です!要素をきちんと分解し、1つのことを1つの項目として書き表すこと、 これがすごく大事な観点だと思っています。なぜならば! 我々は仕様書を書いているのだから。なんだそりゃ!? とお思いでしょうが、仕様書ならではの以下の役割があるからです。■よい設計の観点から 機能ブロックや入力情報等がきちんと…

何だろうが、音楽は欠かせません ~『リファクタリング・ウェットウェア』のまとめ

…は、(...)新しい抽象的なパターンを発見する可能性が高くなるわけです。 「比喩は、言語表現とイメージの双方にとって共通の場」、比喩を使うことは創造性を広げる強力なテクニック 「比喩的思考はプログラミングの基本だ。なぜなら比喩はすべての抽象的な思考に存在するものだから」 虚偽記憶 ― 記憶は読み出しのたびに書き込みが起こる 命名の誤り ― ものに名前を付けると、それが説明できたとか理解できたと思ってしまう 「めったに」は「けっして」ではない 「どんなに薄い墨でも最良の記憶力に…