はてなブックマーク

現代のソフトウェア開発、「複雑性」と「不確実性」との戦いなんだけど、現実問題、性格的に「不確実性」が苦手、とか、向き合いたくない、というタイプの人も居るんだよなーというね 「不確実性」に対する不安感との付き合い方が極端に出がち 間違いない方法を「指示」してほしいんだろうなぁ— magnoliak🍧 (@magnolia_k_) 2023年1月28日 現代のソフトウェア開発のプラクティスは、「複雑なこと」と「不確実なこと」にどうやって対応していくか？というテーマを元に進化を続けている。 そのうち「不確実なこと」に関しては、そのリスクを可視化し、分解していって、それぞれの要素に対する打ち手の数を増やすことと、そのフィードバックに対するレスポンスの速さを支えるプロセスや、ツールの議論が盛んに行われている。 一方で、それを扱う「人」は果たしてそれに対応できているのか？という疑問がある。 上記のツ

継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣 作者:David Farley日経BPAmazon 書名の「継続的デリバリー」はCI /CDの解説書かな？とも思わせてしまうので若干ミスリードなんだけど、「工学とは何か？」「ソフトウェア工学とは何か？」「工芸と工学は何が違うか？」ということを解説した1冊。 『継続デリバリーのソフトウェア工学』を読み始めた そういえば、最近「ソフトウェア工学」ってキーワードを聞かないなーって思ってたけど、本書にも「最近敬遠されてない？」って書かれてた— magnoliak🍧 (@magnolia_k_) 2023年1月28日 まぁ、確かに「ソフトウェアの品質分析がー」とか、「設計書を書けばコードが自動生成ー」みたいな、「管理！」的な価値観が大きかったように思われてたんじゃないかなーとか思った— magnoliak🍧

UEFIのPOWERの設定を確認する Enhanced Power Saving ModeがDisabledになっていること 現代のPCは、電源がオフになっている時でも多少の電力を消費するようになっているけど、それを最小化するための設定。 ただし、これがEnabledになっているとWake On LANは使えず、Wake On Alarmという日時指定の自動起動しか使えなくなる。 また、これがEnabledになっていると、特定のポートに繋がったUSBキーボードからAlt+Pで電源をオンにするためのSmart Power Onも使えなくなる。 Wake On LANを有効にするためには、まず項目がDisabledになっていることが条件。 Automatic Power OnのWake On LANがEnabledになっていること そのままの設定値だけど、続いて当然Wake On LANがEn

マスタリングLinuxシェルスクリプト 第2版 ―Linuxコマンド、bashスクリプト、シェルプログラミング実践入門 作者:Mokhtar Ebrahim,Andrew MallettオライリージャパンAmazon 令和最新版のシェルスクリプトの入門書とリファレンスがセットになった1冊。手元に置いておくと安心感ありますよね。 令和最新版なので、冒頭からデバッグしたいならVisual Studio Code がオススメ、と出てきます。 コンテナ使おうと思ったらシェルスクリプトの読み書きの出番がどんどん増えていって、コンテナに一番必要なスキルはシェルスクリプトのスキルでは？と思っている今日この頃です(違います)が、そのくらいの用途に必要な要素は全部盛り込んであり、シェルスクリプトの文法と実践的な使い方に加えて、一緒に利用されることの多いgrep、awk、sedといったコマンドの解説も併せて載

Software Design (ソフトウェアデザイン) 2023年2月号 [雑誌] 技術評論社Amazon SoftwareDesign、ドメイン駆動設計入門もいいけど、ログの基本もめちゃめちゃいいので、今月号はみんな買ったほうがいいです— magnoliak🍧 (@magnolia_k_) 2023年1月19日 Software Design 2023年2月号、特集が「ドメイン駆動設計入門」と、「ログの基本」の2本立てなんですけど、どちらも凄く良い記事でした。 これは買った方がいいです！ ドメイン駆動設計入門 エヴァンスの「ドメイン駆動設計」で語られれていることをベースとして増田亨さんをはじめとする執筆陣による、とてもコンパクト、かつ分かりやすい解説が怒涛の密度で展開されます。この部分だけでも5000円くらいの価値が有るんじゃないでしょうか。 基本的な考えを把握する、という意味ではこ

引き続きThinkCentre M75q Tiny Gen2上にインストールしたUbuntu Serverの環境構築を続けます。 blog.magnolia.tech メインPCとファイルを共有するためにSambaでファイルサーバを立てることにします。 直接Ubuntu Server上でSambaサーバを立ててしまうと管理が面倒なのでDockerで立てることにします。 Sambaのイメージを選ぶ ネットを検索するとdperson/sambaというイメージを使って構築する事例がよく出てきますが、残念ながらイメージの更新が止まっているようです。 他のイメージを探したところ、servercontainers/sambaというイメージが見つかりました。 GitHubのリポジトリを見たところ、具体的なバージョンを指定するのではなく、定期的にAlpineのイメージを取得してインストールできたSamba

前回のエントリでは、ルータ側のDHCPの設定でIPアドレスを固定化しようとしたけど、上手くいかなかったので、Netplanを使って固定化する方法を調べた。 blog.magnolia.tech 今使っているルータは、MACアドレス指定でDHCPで配布されるIPアドレスを固定化する仕組みを提供しているけど、Ubuntu ServerではDHCPを使ってIPアドレスを取得する際のキーがMACアドレスではなく、DUIDを使っていることがわかった。 IPアドレスを指定するためには、Netplanの設定で、dhcp-identifierという項目に、macと指定する必要があった。 結果的に、設定はこれだけになった。 network: ethernets: device_ethernet: dhcp4: yes dhcp-identifier: mac wakeonlan: true version:

手元のPCにUbuntuをインストールした...よく考えてみると物理PCに直接Ubuntuをインストールしたのが初めてだと気がついた。 特にネットワーク周りの設定は、ネットワークインタフェースに影響を受けるので、今まで意識したことが無いところでの設定が必要になった。 自宅内サーバとしての使い方なのでIPアドレスは固定化したい。 本当はルータ側でMACアドレスを指定してIPアドレス払い出しを固定化する方法も有るはずなのだけど、上手くいかなかったので、まずはUbuntu側で設定することにした。 Ubuntuでは、netplanというコマンドを使ってIPアドレスを固定化する。 詳しい解説は、以下のサイトを参照のこと netplan.io 公式ドキュメントでも、ネットの情報でも、明示的にrendererを指定している例が多いけど、公式ドキュメントには/etc/netplan/配下にYAMLファイル

普段、メインで使っているPCがMacBook Air 2018なので、さすがにDockerでコンテナをたくさん立ち上げたまま、ブラウザで調べ物する、みたいな使い方が辛くなってきた。夏場はファンも凄い回っちゃうし、レスポンスはすごく悪くなるし。 メインPCを買い替えようかとも思ったけど、ブラウザを使うくらいの作業なら特に不満は無い。それにそもそもメインPCでLinuxが動いている必然性も無いし、画面も要らないのでサブPCとしてデスクトップPCを用意して、Linuxをインストールする方に方向に転換。 部屋に大きなデスクトップが有るとサイズ的に圧迫感が有るし、複数のマシンのファンの音が同時に鳴るのは苦手なので（データセンタではないので...）、作業している場所から離れた所の隙間に設置できるような、1リットルサイズの小型PCを探すことにした。 Amazonとかで探すと色々と出てくるけど、それなりの

TP-Link 5ポート スイッチングハブ ギガビット 金属筐体 設定不要 ライフタイム保証 LS105G TP-LinkAmazon 自宅サーバ構築用にPCを購入し。 blog.magnolia.tech 作業している部屋で使えるLANのポートが一つしかなく、有線LANと、無線LANのアクセスポイントが同時に利用できない。無線LANでもいいか……と思って作業を始めたけど、Ubuntuのインストールに異常に時間がかかるし、起動のたびに無線LANの接続に数分余計にかかるし、そもそもクライアントPCからのSSHが気持ち悪い遅延が発生して使い物にならない…… さっさと一番安いスイッチングハブを買ってきて接続。 手元の間に合わせだったので一番安い1Gbp対応のものを選ぶだけかなーと思ったけど、実際に買おうとすると選択肢も多いので、小一時間悩んでしまった。 通信速度(1Gbps、2.5Gbps、10

機関車トーマスの「事故はおこるさ」の歌詞は全エンジニアが読むべきなんだけど、ほんとマジであの歌詞の通りのことが起きます— magnoliak🍧 (@magnolia_k_) 2023年1月13日 大事なことが、全部ここに集まっている！ utaten.com きかんしゃトーマス オリジナルソングス VOL.2 アーティスト:戸田恵子,バーティー,パーシー,エドワード,ヘンリーポニーキャニオンAmazon

WEB+DB PRESS Vol.132 技術評論社Amazon 初めて「オブジェクト指向」というキーワードを聞いてからだいぶ長く経っていて、「これはオブジェクト指向らしいコードなのか？」みたいな見方をすることも無くなって久しい今日この頃ですが、WEB+DB PRESS最新号Vol.132 の特集が『オブジェクト指向神話からの脱出』という興味深いテーマだったので読んでみました。 そういえば、20世紀の終わりから21世紀の初めの頃にかけては、オブジェクト指向以外にも色々な開発方法論とそれを支えるツール群が出てきては消えていった時代だった記憶があります。今ではまったく聞くことも無い設計方法論や、ツールがソフトウェア開発の問題への画期的な解決策と宣伝されていました。 で、たいていそのツール費用が高額な上に、更にトレーニングを受けないと使いこなせないし、更にそのトレーニング費用が高額だった...印

ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用 作者:田中 ひさてる技術評論社Amazon 予約してまで買ったものの、なかなか時間が取れず、読めていなかった『ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用』をようやく読み終わりました。 筆者である田中ひさてるさん自身で描かれた表紙の可愛らしさからは想像もできないハードな内容なので、一気に読もうとすると「分かった気」になるだけで全然理解していなかった、ということになりがちなので、3回くらいぐるぐる読むといいと思います（そうです、この本は本文もイラストも丸っと同じ人が書いているのです！！）。 目次 第1章 クリーンアーキテクチャ 第2章 パッケージ原則 第3章 オブジェクト指向 第4章 UML（統一モデリング言語） 第5章 オブジェクト指向原則 SOLID 第6章 テスト駆動開発 第7章 依存

ソフトウェアエンジニアに必要な資質の一つ目は「エラーメッセージが出たら、読んで理解しようとする姿勢」です— magnoliak🍧 (@magnolia_k_) 2022年12月11日 最近のプログラミング言語の傾向として、エラーメッセージを改善して、より分かりやすいメッセージが出力されるようになっていますね。 gihyo.jp techlife.cookpad.com 上記は、PythonやRubyの事例ですが、最近の言語はどれもエラーメッセージが親切になってきました。 それでも読まないのはなぜなんでしょうね…一番の近道だと思うんでけどね。 とはいえ、エラーメッセージを読むだけで解決するバグばかりでもないので、エラーが解決しない時にさっさと方向転換するのも大事な方針ですよね。 二つ目は「何処で作業を打ち切って方向転換するか判断しようとする姿勢」です— magnoliak🍧 (@magn

ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用 作者:田中 ひさてる技術評論社Amazon 「ちょうぜつエンジニアめもりーちゃん」で知られる(?)田中ひさてるさんの本がついに出版される!!(ので、速攻注文した) PHPぜんぜん分からないけど...... 12月10日発売なので、年末は『ちょうぜつソフトウェア設計』を読んで過ごすことにしました。 ちなみに、「ちょうぜつエンジニアめもりーちゃん」って何？って人は、Twitterのハッシュタグ「#ちょうぜつエンジニアめもりーちゃん」でチェック！ twitter.com

「ソフトウェアエンジニアは、一定のレベルを超えると、表示されていない全角スペースの存在を察知できるようになると言われている」— magnoliak🍧 (@magnolia_k_) 2022年11月23日 それなりの経験を積んでいくと、エディタのカーソルの動きとかエラーの出方とかで、「あーここに全角スペースが有るんだろう」みたいなエスパー力が身に付くわけだけど、人類は道具で進化するので、フォントが最初から全角スペースを可視化してくれていればそんな努力(?)の必要は無くなってしまう。 手前が作ったフォントを使ってるせいで、見えていない全角スペースへの感度は無くなってしまった https://t.co/xi8p1f26FM— たわら ¦¦ HackGenのひと👨‍💻 (@tawara_san) 2022年11月24日 crlf「おっと」 tab「オレたちを」 nbsp「忘れてもらっちゃ」

［試して理解］Linuxのしくみ　―実験と図解で学ぶOS、仮想マシン、コンテナの基礎知識【増補改訂版】 作者:武内 覚技術評論社Amazon 2022年も良い技術書がたくさん出版されましたが、その中でも『Linuxのしくみ』はぜひ手元に置いておきたい1冊ですね。 特に、主にアプリケーションレイヤーを主戦場としている人たちにとって、OSは各種ミドルウェアと比較すると「よく分からないもの」という存在になりがちです。しかし、OSがなければアプリケーションも動かないわけで、基本的な知識としてこの本に書かれているようなレベルのことを押さえておくと性能が出ない時に無闇に資源を増やす前に考えるべきことの気づきが得られます（無闇に資源を増やす、という選択肢が取れる時代になったのは、それはそれで良いことですが） 特に、前半のプロセス周りは、「sar」「taskset」など自分も今までちゃんと使ったことがない

説明のために手順を確認したので、その覚書。 作業環境にリポジトリを用意する github.com $ git clone git@github.com:isucon/isucon12-qualify.git Dockerをインストールする www.docker.com 値上げが最近話題になりましたが、個人利用は無料です。 www.docker.com 次回はRancher Desktopを試してみます。 rancherdesktop.io docker-compose.ymlを書き換える 一箇所だけ書き換えないと、起動しません。 Docker Hubから「mysql/mysql-server:8.0.29」のイメージが無くなっていて、MySQLが起動できません。8.0.30以降のバージョンを指定しましょう(無くなった理由は探せませんでした...)。 2022/11/06追記 mysql-s

設計の「why」を言語化できる人は強いんですよ— magnoliak🍧 (@magnolia_k_) 2022年10月29日 っていうか、驚くくらい「why」が上手く表現できないんですよ、普通は 手順は言えても、なぜ？が言えない— magnoliak🍧 (@magnolia_k_) 2022年10月29日 設計において、すべての決定について仔細に「なぜ、そうしたか？」を言えるべきなのだけど、これを上手く言語化できない人は多い。「このプロジェクトでは以前からそうしているから」「そうするのが当たり前だと思っていた」などなど、本当に理解してないまま「設計という作業」を進めている人もいれば、上手く自分の行為を言語化できないだけの人もいる。 また、必ずしも自分が設計したことについて説明する場面ばかりとも限らない。既に存在する設計から「なぜ」を類推するしかない場面もある。他人のコードを読み取るとき

原著が出てたときから割と気になっていた「ベタープログラマ」を読んだ。 全体的な感想 第Ⅰ部はコードスタイルや、不要なコードの存在、テストコードを書く話など、非常に実践的な内容が多かった。 第Ⅱ部は割と考え方というか、思想的な話になっていって、第Ⅰ部をきちんと読んで危機感を持って行動を変えられる人であれば自然とそこに到達するのでは？と思った。 まずは第Ⅰ部をしっかり読んで、自分の置かれた環境との差異や、これから行動することを書き出す、みたいな読み方をすると良い。 第Ⅲ部以降は、もう完全に生き方というか、エンジニアとしての振るまいや、哲学の話になってくるので、一気に通読する、というより少し間を置いて拾い読みしながら読み進めて行くと良いかも。 流し読みしても全然役に立たないタイプの内容なので、読書メモは必ず書いた方がいいと思うし、書かれていることが万人にとって正解、といった類いのものでもないので

「エラーメッセージ対応1000本ノック」みたいなのが実は1番スキル上がっちゃうんじゃないかなぁ でも養殖もののエラーじゃだめなんだよなぁ 天然物じゃないと それができたら、もっとヤバい「エラーが出ないけど、結果がおかしい」にチャレンジしよう— magnoliak🍧 (@magnolia_k_) 2022年9月3日 上記ツイートの引用RTが学びに溢れているので、みんな見て欲しい。 独学で「エラーメッセージをちゃんと読む」という習慣を身につけるのはなかなか難しい。 そもそも色んな出力が、ばーっと出てきて、どれがエラーメッセージなのかも分からないし… エラーへの対応スキルが、仮に、以下のような6つの段階が有ったとして、少なくともステップ3までは適切な人に指導されないと、正しいやり方は身につかないよねぇ。独学で身につけられた人は、「独学でできる、というスキル」がある人だしね。 そもそも「今、エラ