なぜオブジェクト指向方法論に代わる方法論が出ないのか - きしだのHatena
1990年代にオブジェクト指向分析・設計の方法論がめちゃ流行ったことがあります。 ただ、そのブームが終わって、後続となるような方法論が流行ることはありませんでした。 で、なぜなのか考えていたのですけど、オブジェクト指向方法論のウリは分析段階で出てきたオブジェクト(といいつつクラス)がコードにそのまま引き継がれるというものでした。ようするにオブジェクト指向方法論というのはコードのスケッチを書いて詳細化していくというものだったのです。 しかしながらこれは、スケッチとして書いた分析・設計が間違っていればコードも間違うわけで、強くウォーターフォールの性質をもつものでした。 結局のところスケッチの妥当性というのはコードを書かないと検証ができません。分析・設計段階で見出されたクラスが妥当かというのは、コード書かなければわからなかったのです。逆に、コードを書けば妥当かどうかわかります。であれば、最初から
「Rustでやると知らないうちに詰む設計」を避けるためのTipsを集めてみる
とりあえず、よく言われてるやつから埋めていこうと思う。 構造体にライフタイムを持たせない 構造体にライフタイムを持たせるのは「基本的に」避けよ、というのが重要なのは間違いないのだけど、これをもう少し実践的な内容にしたい。ちょっと考えてみたけど、こういうのはどうだろうか。 ある関数呼び出しの中でしか絶対に使わない。returnするまでにその構造体のデータは全て破棄される。static変数に退避させることもできない。アロケーションもその関数が面倒を見る。そういう一蓮托生できる関数呼び出しに心当たりはあるか？ ある→ 構造体にライフタイムを持たせてもよい。 ない→ ライフタイム禁止。 そう考えてみると、DIとかReduxとかとも通じるところがあるかもしれない。「つべこべ言ってないで全部の責務を一番外側に持っていく」という決断ができるときは構造体ライフタイムが選択肢に入る。
Go言語が好きな理由
はじめに 私はGoが好きなので、disられている場面に遭遇すると心が痛みます。残念ながらプログラミング言語について深く語れるほどの知識や経験は持ち合わせていないため、世界が平和になることを祈るくらいしかできません。 （元ネタ）Go言語を嫌う6個の理由 - さめたコーヒー それはそれとして、Goが好きな理由を語る人はあまり見かけない気がします。この記事ではGoが好きな理由を視覚に障害のあるユーザーの視点から語ります。読み終えたところで得るものは何もありませんし、長いので覚悟して読んでください。 あなたは誰？ 4年ほど業務でサーバーサイドのGoを書いています。また、業務で使いはじめる前から趣味でGoに触れていました。そのため無意識の内にひいきしているかもしれません。ただし、流行っているからといって理由もなくGoを勧めたりはしません。 視覚障害ならではのコーディング事情 Goが好きな理由と深く関
【PHP8.1】PHPで簡単に非同期処理を書けるようになる - Qiita
PHPは長きにわたり同期的、すなわち、あらゆる処理を上から順に実行していくというスタイルを取ってきました。 しかしたとえば、複数のURLからデータを取ってきて結果をまとめたいといった場合、時間のかかるHTTPリクエストは同時に投げたいですよね。 この用途にはGuzzleというライブラリが存在し、これを使えば同時にリクエストを投げられます。 しかし、ではHTTPアクセスとDBアクセスを同時にやりたい場合は？ 時間のかかる計算を裏でやりたい場合は？ などと考え始めると、こういった個別のライブラリでは対処しきれません。 ということで汎用的な非同期処理をPHPで書けるようにするRFCが提出されました。 PHP RFC: Fibers Introduction 人類史上ほぼ全ての期間において、人々はPHPを同期的なコードとしてのみ書いてきました。 同期的に実行されるコードのみが存在し、そしてそれを同
React Server Componentsに感じたフロントエンドの消失
はじめに 新年早々に面白そうな記事を見つけました。ReactでのAPI呼出しを最適化するために「部分的にサーバサイドで実行するコンポーネントを作る」というもののようです。 あるいは去年の記事ですが気になってたものとしてBlitz.jsでReactベースのFWであるnext.jsに永続化層を持たせてRailsのようなFWにしようというアプローチもあります。 どちらの記事も書かれてる内容自体は分かる気がするものの 「それをフロントエンドでやる意味あるの？」 というのが拭えずイマイチ腑に落ちなかったんですが、単純に 「私と最前線でやられてる方々で期待してるものがたぶん違う」 という気がしてきたので、その辺を整理のために書いてみます。 注意書き Vue.js/Nuxt.jsは少し触ったことがありますが、React Server ComponentsやBlitz.jsを触ったことは無いです 「なんで
プログラミング初心者は変数名やメソッド名を略さない方がいいよ、という話 - give IT a try
今回のエントリでは先日、僕が勤めているソニックガーデンで話題になったプログラミング関連の小ネタを書きます。 それは何かというと、「プログラミング初心者は変数名やメソッド名を略さない方がいい」という話です。 長い変数名やメソッド名はつい略したくなります。 実際、僕も長い名前を略すときはよくあります。 ですが、略称を使うのは長年の経験から「この略称は一般的だから誤解を招くことはきっと少ないだろう」とか「前後の文脈から、変数の中身は誰が見ても明らかだろう」という想像が付いた場合だけです。 一方、プログラミング初心者の人は経験が浅いため、「一般的かどうか」とか、「誤解が発生しないかどうか」といった判断ができません。 そのため、他の人が見たときに「え、何この変数名？」と思ってしまうような略称を付けてしまう恐れがあります。 たとえば、先日のコードレビューで、初心者の人がrev_noという名前の変数を定
「Goの父」ロブ・パイクの「プログラミング5カ条」、ネット上で話題に
「UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている」「キャッシュはアーキテクチャではない。単なる最適化だ」などの語録を生んだ「Goの父」とも呼ばれるロブ・パイク氏の「プログラミング5カ条」について、ネット上で話題となっています users.ece.utexas.edu/~adnan/pike.html http://users.ece.utexas.edu/~adnan/pike.html Rob Pike's Rules of Programming (1989) | Hacker News https://news.ycombinator.com/item?id=24135189 パイク氏の「プログラミング5カ条」は以下。 ルール1：プログラムのどこで処理時間がかかるかはわからない。ボトルネックは意外な場所で発生するので、ボトルネックがどこにあるかを証明するまでは、臆測
さよならアーキテクチャ議論｜Seiji Takahashi@ベースマキナ
ポエム。 つまり？予算やチームのリテラシーに合わせて最速で作れて、チーム内で「俺ら高凝集低結合だなー」と思えるなら、アーキテクチャはなんでもいいと思えてきました。 前提・まだ割と収益が安定してないプロジェクトでの話です。お金があるなら好きにやりましょう。Go Bold。 ・DDDやクリーンアーキテクチャがダメとは言ってないです。むしろ自分は直近そこまで厳格ではないクリーンアーキテクチャでAPI書いてます。 ・以前こういうポスト書くくらいにはアーキテクチャのこと試行錯誤してました。 アーキテクチャ導入議論への疲労以前僕は、DDDやクリーンアーキテクチャを導入するという話が出ると積極的に顔を出すようにしていました。でも、最近は「導入しましょう」「既に適用してあるのでキャッチアップしてください」などの議論をするのに少し疲れてしまい、足が重くなったように感じます。もうおじいちゃんなので体力がないん
7つの設計原則とオブジェクト指向プログラミング - ソフトウェア設計を考える
設計原則はよい設計をするための指針です。 では、よい設計とはなんでしょうか？ もっとも重要なソフトウェア品質は発展性 ソフトウェアの発展性がビジネス価値を生む 発展性をうみだす７つの設計原則 モジュール化 モジュール化の２つのアプローチ 型によるモジュール化 手続き的なモジュール化 関心の分離 関心の4象限 入出力と計算・判断の分離 業務の関心と実装の詳細の分離 もっとも複雑な関心事（ビジネスロジック）の分離を徹底する カプセル化と抽象化 カプセル化 ビジネスロジックのカプセル化 抽象化 データ抽象 ビジネスロジックとデータ抽象 高凝集と疎結合 凝集度 結合度 隠された結合性の問題 定義の一点性 見た目が同じコード 7つの設計原則の学び方 コードの実装例 ドメインオブジェクト設計のガイドライン 実践ガイドとして使える本 設計の考え方を理解するための本 もっとも重要なソフトウェア品質は発展性
メルセンヌツイスタはそんなに衝突しない - Qiita
κeenです。こちらのスライドが話題になっているようです。 10秒で衝突するUUIDの作り方 - Speaker Deck 笑い話としても乱数の難しさの側面としても面白いのですが、これを見た人たちの反応がちょっと勘違いしてそうだったので補足します。 別に私は暗号とか乱数とかの専門家ではないです。 発表者の方のコードは読みましたか？ 少し速度が必要になるのでRustに移植します。 [package] name = "genuuidv4" version = "0.1.0" edition = "2018" # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html [dependencies] rand = "0.7.2" sfmt = "0.6.0" use
Node.js徹底攻略 ─ ヤフーのノウハウに学ぶ、パフォーマンス劣化やコールバック地獄との戦い方｜ハイクラス転職・求人情報サイト AMBI（アンビ）
Node.js徹底攻略 ─ ヤフーのノウハウに学ぶ、パフォーマンス劣化やコールバック地獄との戦い方 Node.jsをうまく活用できている企業は、どのような方法でベストプラクティスを習得してきたのでしょうか。ヤフー株式会社でNode.jsの社内普及に務めてきた言語サポートチームに、同社の実施を紹介してもらいました。 Node.jsは「イベントループモデルで、ノンブロッキングI/Oを使用している」「問題発生時にHTTP/TCPやPOSIX APIなど低レイヤーの知識を求められる」といった特徴を持つ言語です。開発者が習得すべき技術領域が広いため、Node.jsらしい書き方の学習難易度は高いと言えます。 それでは、Node.jsをうまく活用できている企業は、どのような方法でNode.jsのベストプラクティスを習得してきたのでしょうか。ヤフー株式会社でNode.jsの社内普及に務めてきた言語サポート
パイプライン演算子の歴史 - まめめも
(You can read this article in English.) Ruby の開発版にパイプライン演算子（pipeline operator）が試験的に導入されましたが、いろいろあってプチ炎上になっています（チケット）。 せっかくの機会なので、パイプライン演算子の歴史を調べてみました。付け焼き刃の調査なので、間違ってたら教えてください。 パイプライン演算子とは こんな感じのものです。 x |> f |> g |> h # h(g(f(x))) と同じ意味 h(g(f(x))) という関数適用の式は、関数が呼ばれる順序（f→g→h）と、プログラムの字面上の順序（h→g→f）が逆でわかりにくいとされます。この問題は、特に、関数が大きくなったときに顕著になります。 wonderful_process_h( marvelous_process_g( fantastic_process
何かを「決定する」メソッド名
プログラム書いてて、何かの値を A か B か決める、みたいなメソッドの名前ってみんなどう付けてる？ 算出する、みたいなやつは calculate_xxx ってしてるけど、パラメータに応じてどっちか決めるだけ、みたいなメソッド名のいい名前が思い浮かばない・・・ なんかイマイチしっくりこない感があるんだけど、determine_xxx とかでいいのかなぁ？
プログラマの実力は経験だけであがらないことがレベル格差につながる - きしだのはてな
プログラマというのは、道具に慣れることが、実力があがることにならないのですよね。だから、勉強せず業務経験だけだとレベルが低いままということになってしまう。 Javaを10年さわり続けて、Strutsを5年さわり続けても、それだけでは、与えられた画面を手際よく作成できるようになるだけで、たとえばStrutsすらよりよく使えるようになるわけではなかったりする。 Javaにしても、「volatileってなんですか？」という問いに、まあ知らないのはしかたないとしても、解説を見ながらですら答えられない可能性がある。 プログラムの反復生産は、プログラミング能力の向上にあまりつながらない。設定や記述に慣れるだけだ。そして、この「慣れ」というのには「難しいからそもそも実装を回避する」というようなものも含まれる。実力の向上は、作業ができるレベルで止まってしまう。 プログラマとしての実力をあげるための勉強が自
Rubyコミッター・Yuguiに学ぶ、コードに書くべき「適切なコメント」と「適切な場所」 - エンジニアHub｜Webエンジニアのキャリアを考える！
Rubyコミッター・Yuguiに学ぶ、コードに書くべき「適切なコメント」と「適切な場所」 Rubyコミッター・園田裕貴（Yugui）さんが、長年の経験で体得したソースコードに書くべき「コメントの技法」を教えてくれました。 プログラミングにおいて、どんな初心者でも書けるけれど、適切に書くのは上級者でないと難しいもの。それがコメント（=ソースコードに書かれている注釈やメモ）です。 不適切なコメントをつけても、プログラムの動作には影響しません。しかし、書き方の巧拙によって、コードの可読性や理解のしやすさには雲泥の差が出ます。良質なコメントが良質なコードをつくるのです。 今回はRubyコミッターでありgrpc-gatewayの開発者でもあるSupership株式会社の園田裕貴（Yugui）さんに、優れたエンジニアがどんな観点を持ち、どんなコメントを書いているのかを聞きました。 園田 裕貴（そのだ・
「設計なんて不要でしょ」について - Qiita
経緯 以前とある席で偶然シニアエンジニアの方と設計について議論することがありました。 その時に特に耳に残っていたのは以下の様な内容です。 クリーンアーキテクチャってテストしやすくする為のですよね？ 設計はコード書ける人が他のコードを書ける人に威張るための道具なのではないか？ 設計を学習するならブロックチェーンとかを勉強して技術力を高めるべきなのではないか？ リーダブルコードさえ読んでいれば設計は必要ないのではないか？ 設計なんて不要でしょ その方はかなり詳しく設計の歴史をしっていて尤もな事を言っていましたが、平成も終わる頃においてはその限りではないです。 なので平成最後の日にそれら全てに対して最終的に解答できる形で設計の有用性を説明し、気持ちよく令和を迎えます。 注意: 一応ここで説明する内容や要素も一面だけです。 よくある誤解 クリーンアーキテクチャといえばこの有名なリングですよね。 こ
10xプログラマーという神話｜zaq1tomo
10xプログラマー、それは「一流のプログラマーが普通のそれと比べて10倍の生産性をもつ」というソフトウェアエンジニアの世界における神話です。 「多くの人が必要とするものを創れるようになりたい」 そんな想いからこれまで、Gunosy、Mercari、LINEなどでエンジニアとして働いてきましたが、直近、今後進むべき道について見つめ直す機会があり、「良いエンジニアとは何なのか」について自問する時間がありました。 その過程で、Redisの作者Salvatore Sanfilippoによる「The mythical 10x progrmmer」と出会い、非常に為に内容が多かったため、本人に翻訳させて欲しいと申し出たところ、「Sure!」と快諾して頂いたため、僭越ながら共有させて頂きます。 Salvatore Sanfilippo（@antirez） - http://invece.org/ - h
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ふつうのプログラマのふつうの設計
10秒で衝突するUUIDの作り方
一時期プログラミングのデザインパターンというものが大流行しましたが、現在ではどのように評価されているのでしょうか？
