小堀友樹 @hikikobori 会社にて30年前くらいの「シーエム ナウ」があったので何気なく読んでみたら、あまりにおもしろくて、個人的にオークションを漁り、40冊くらい買ってしまった だってバーモントカレーのりんごシズルマシンの構造とか載ってるんですよ 最高すぎませんか pic.x.com/8uv2yh7tog
qianchong.hatenablog.com こんな記事を読んだ。記事内で当ブログに言及していただいており通知が飛んできたので読んだのだけれども、内容的には「SF映画やAIや技術系の本も大好きなのに、SF小説は最後まで読み通せないものが多い」ということで、なぜなのだろう、老いなのだろうか、と疑問を呈している。率直な感覚が綴られた、良い記事だ。 SFって読み通すのに労力がいるよね SF小説を読んでいる方の人間である僕にとっても「わかる」と頷くところが多い記事だった。SF小説って、ブログ筆者の方も次のように書いているけれど(『SF小説というものは、類まれなる想像力でこれまでに我々が見たことも聞いたこともないような世界を紡ぎ出すところがその真骨頂だと思います。でもおそらく私は、その想像力が紡ぎ出す世界に自らの想像力が追いついていかないのでしょう。』)、想像力が追いつくかどうか以前に「読むのに
SF映画は大好きなのですが、小説となるとどうしても最後まで読み通すことができません。とはいえ中高生の頃は『宇宙英雄ペリー・ローダン』シリーズみたいな、いわゆるスペースオペラ的作品をたくさん読んだような記憶があります。でもよくよく思い返してみるに、SF好きの友人のおすすめ本をいくつかかじって何となく読んだような記憶がでっち上げられていただけで、実際にはほとんど読めていなかったのかもしれません。 SFといえば、ずいぶん前に「日本SF大会」というイベントで通訳業務を仰せつかったことがあって、その時にSFファンのみなさんの盛り上がりぶりに接して、憧れのような気持ちを抱きました。ああ、この輪の中に入ることができたら楽しいだろうなと。それ以来、何度も間欠泉的に挑戦してきたのです。 https://www.irasutoya.com/2018/06/blog-post_264.html 最初はまず古典か
いただきましたー!わーい。脳に収めるぞー! @haradakiro @ryuzee pic.twitter.com/3Qd6EvPioU— SHIIBA Mitsuyuki (@bufferings) June 13, 2024 明日(2024年6月18日)発売! www.oreilly.co.jp どう書くのがいいんだろうなぁ? 複雑なコードと向き合うときは「あー、これはメモを取りながら読まないと迷子になるやつだ」ってなる。最初はわりとキレイに作られていたとしても、機能追加を重ねていくとだんだん読めなくなっていく。 だから「時間が経っても読みやすいコードってどう書くのがいいんだろうなぁ?何かヒントがあるかなぁ?」って思いながらこの本を開いた。先に書いておくと、ヒントはあった。 アウトサイドインのTDD 全然予想してなかったから、おー!と思ったのが、説明をTDDで進めていくってところ。好き
ソフトウェアは複雑さを増すばかりですが、人間の脳は限られた複雑さしか扱えません。ソフトウェアが思い通りに動くようするには、脳に収まり、人間が理解できるコードを書く必要があります。 本書は、拡張を続けても行き詰ることなくコードを書き、複雑さを回避するための実践的な方法を解説します。最初のコードを書き始めるところから機能を追加していくところまでを解説し、効率的で持続可能なペースを保ちながら、横断的な問題への対処やトラブルシューティング、最適化を行なう方法を説明します。自分のチェックリストからチームワーク、カプセル化から分解、API設計から単体テストまで、ソフトウエア開発の重要な課題に対する考え方やテクニックを紹介します。サンプルプロジェクトで使うコードは、Gitリポジトリの形で入手でき、試しながら学べます。 有効に機能するプロセスを選び、効果のない方法論から脱却する方法。チェックリストを使うこ
デイリーポータルZ読者にはおなじみの古賀テンションだが、日記本で古賀さんを知った人にはこのテンションで良いのか不安になる。 だって本ではこんな感じである。 昼は私も娘も各自好きに食べ、午後リモートでうちあわせをしているうちに娘は作文教室へ行った。 PCのファンの音がとまり、IHコンロのファンの音もとまり、私以外には誰もおらず、すると一気に静かになった。うるさく感じていたわけでもなかった音がやむ、その瞬間の雰囲気が好きだ。 (「ちょっと踊ったりすぐにかけだす」 p.236) 生活のなかの一瞬を描写している。 この日記の書き方を習うために散歩してその様子を書くことにしたい。習うのは林。編集部の橋田さんにも話し相手として散歩に同行してもらった。 まずは散歩の様子をいつものデイリーポータルZ風にざざっと記し、そのようすを古賀・林がどのように日記にするかを検証したい。 まずはいつものデイリーポータル
はじめにTIG EXU真野です。 積読を消化しようというテーマの、読書感想文連載 の1冊目は、単体テストの考え方/使い方 です。 書籍の基礎情報です 2022年12月28日発売 Unit Testing Principles, Practices, and Patterns の翻訳書。原著は2020年1月14日に発売 テーマ 質の高いテストを行い、ソフトウェアに価値をもたらそう! 単体(unit)テストの原則・実践とそのパターン プロジェクトの持続可能な成長を実現するための戦略 単体テストの原則・実践とそのパターン コード例は C# であるものの、どの言語でも適用できる汎用的な内容とのこと 中を見ると、微妙にC#特有ぽいところに1箇所悩みましたが、それ以外はその通り 翻訳者の須田さんは、他にもセキュア・バイ・デザイン: 安全なソフトウェア設計 やOAuth徹底入門 セキュアな認可システムを
最近家の本の電子書籍化に着手している。もともと僕は本は大量に買うが、それをいつまでもとっておくのではなく、定期的に売るか捨てるかしていた。理由は単純で、家が狭く、引っ越しが多いからだ。転職も多く、乗り物酔いがひどく、電車に乗っただけで吐きそうになるので、毎回会社の徒歩圏内に引っ越す必要があるのである。 一人暮らしなので当然ワンルームだ。そうすると、本を何千冊も置いておくスペースは存在しないし、持ち運ぶのも非効率だ。なので、泣く泣く本たちを処分する。過去の本を参照する必要がある時も多いが’、そういう時は諦めて2000円の本だろうが、古書で5000円になっていようが、諦めて買い直していた。その再購入費用はだいたい年間5万〜10万程度で、場所代・保管費よりは安い、という塩梅であった。 ところが、先日SF年間ベスト記事で告知を出したが、いまSFについての本を書いていて、大量の本を買い直したり資料を
Twitterに書こうかと思ったけど、明らかに字数オーバーするのでブログに書きます。 タイトルの通り、技術書を紙の本で読むか、電子書籍で読むか、という話です。 結論からいうと、僕は基本的に紙の本を選びます。 紙の本のメリット3つ(+1つ) 1. 自分にプレッシャーをかけられる 一番の理由は、机の上に置いて「最後まで読め」と自分にプレッシャーをかけられるからです。 上の写真のように、いやでも目に付く場所に常時置いておくことで、思い出す機会や手に取る機会を増やすことができます。 これが電子書籍だと姿形(すがた・かたち)が見えなくなるので、強い意志を持っていないと「積ん読」のまま終わってしまう可能性が高くなります。 参考:ちなみに今読んでいる本はこれです↓ プログラミングTypeScript ―スケールするJavaScriptアプリケーション開発 作者:Boris Cherny発売日: 2020
電子書籍の登場で紙の本が売れないなんて意見をよく見るけど アメリカじゃそんなことなくて2010年ごろに騒いでた電子書籍ブームはもう終わってて 紙の本が復活なんて言われてたりするんだけど じゃあなんで日本は相変わらず紙の本がだめなのかって考えるとさ 技術書見てもわかるよ日本の問題が 少子化高齢化ももちろん問題だけど、やっぱり本の内容だよね どいつもこいつもはじめての〇〇系じゃん? それも300ページくらいのあさいやつばっかり アメリカじゃ初心者向けでも500ページくらいあって、丁寧に書かれていたりするし なにより2冊目3冊目の中級の本もあるし、上級の本も充実してる もうね、まるでレベルが違うんだよね 上級者向けだと1000ページあったりするじゃん?w 翻訳した本じゃないとないよねそういうの 日本人の本ってつまみ食い系の本ばっかりなのよ そうするとネットでいいじゃん、ブログで良いじゃんってなる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く