GoとRustの変更処理を比較することで両者を深く理解する試みです。 詳しい内容やスライドでは省いたところをブログに書きました https://zenn.dev/nasa/articles/compare_rust_go_concurrency

2022/02/28 に MoneyForward で発表した A Philosophy of Software Design の話です。
(編注:2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) オブジェクト指向プログラミングが、ソフトウェア開発に新しい設計を持ち込みました。 その結果、開発者は単一の目的を処理するために、全体のアプリケーションに関係なく、1つのクラスの中で、同じ目的や機能を持つデータを結び付けることができるようになりました。 しかし、このオブジェクト指向プログラミングで、分かりにくいプログラムやメンテナンスができないプログラムを防ぐことはできません。 そこで、5つのガイドラインがRobert C. Martinによって作り出されました。これら5つのガイドラインすなわち原則により、開発者にとって読みやすく、メンテナンスが可能なプログラムを作成しやすくなりました。 5つの原則は、S.O.L.I.Dの原則と呼ばれています(頭字語はMichael Feathereによって名付けられま
社内のSlackでUI談義が突発的に始まることがあるのだけれども、以前そこで上がったiOS純正メールアプリのUIについてのネタがなかなか面白いのでまとめてみようと思った。結論から言うと、純正メールアプリ、ヤバイ。 まずは観察メールの新規メッセージ画面は他の純正アプリではあまり見かけないようなトランジションを採用していて、開くと元の画面が少し後ろに下がってナビバーだけが見えつつもメッセージ画面が中途半端なモーダルビューで現れたような状態になる。このUIが使いやすいとか何となく見た目がかっこいいとか、そんな上辺だけの理由では絶対ないはずなので、AppleがメールアプリをデザインするときになぜこのUIに至ったのか、その理由を考えてみた。 メールの新規メッセージ画面を開いた状態普段純正メールアプリでメッセージを送信することはほとんどなかったので、まずはいろいろと動きを観察することにした。新規メッセ
さて、このタイトル、かなり挑発的ですよね。それは認めます。もう少し説明すると、私は大胆なタイトルが好きなのです。人の注意を引くことができますからね。とにかく、この記事では、Goがひどい設計の言語(実際、本当に全て台無しになります)だということを証明していこうと思います。私は既に数カ月間Goで遊んでいますし、たしか6月のいつだったかに初めてHello, Worldを走らせてもみました。私は数学がそんなに得意ではありませんが、あれから既に4カ月経っていますし、 Github 上のパッケージもいくつか手に入れました。言うまでもありませんが、私は仕事でGoを使ったことは全くないので、”コードサポート”や”デプロイ”やそのあたりに関する私の意見は話半分で読んでくださいね。 私はGoが大好きです。使ってみて大好きになりました。慣用表現を理解したり、ジェネリクスがないことや、おかしなエラーハンドリングや
みんなのウェディングの高井です。 クラスベースのオブジェクト指向プログラミング言語を利用している人であれば、クラスとは、ありふれていて普段から利用するものです。にもかかわらず、良いクラスをつくるというのは、なかなかに難しいことです。 先日、みんなのウェディングでアルバイトをしてくれている学生さんのコードレビューをしていたときにも、それを強く感じました。 実践的プラグマティックには「ソフトウェアの規模や文脈にあわせて、適切に抽象化していただきたい」という以上のことを言っても仕方がないところなのですが、それだけでは経験の浅いプログラマーにとって、まったく分からないという話になってしまいます。 というわけで、今回はクラス設計の原則についてのお話しです。 Bertrand Meyerのクラス設計の原則 Bertrand Meyerは『オブジェクト指向入門 第2版』の中で、クラス設計について章をひと
ソフトウェアを作ってて、作り直したり、書き直したりするべきかどうかという話をすることがある。 大きな規模だと、ソフトウェアを作り直す、というところから、小さな規模だと、込み入った機能を書き直す、くらいまであるけど、作り直すとうまくいくのは、次の二つのうちどちらかではないか。 最初に作ったときより世の中の技術が発展したとき 昔のコンピュータでは収まらなかったとか、昔は良いライブラリがなかったけど、今はある、というとき。 単に今ありふれた技術で作り直すと、よいものができそう。 最初に作ったときよりはコンピュータのスペックが上がったので、そのつもりで、並列度倍に上げても止まらないし、より速く動かせる、とか。 昔はバッチで計算しないといけなかったけど、今ならリアルタイムに返せる、とか。 昔は依存管理のよいライブラリがなかったけど、今ならこれ入れたら簡単、とか。 最初に作ったときより人間の技術が発展
それとも、”私はデザイナーなので、そんなことを知る必要はありません”と言い張るのか 私の職業はデザイナーです。私はエンジニアが好きです。ちょっと度が過ぎるくらい好きかもしれません。以前、Facebookの グループ に参加した時、かなり前からチームのメンバであるiOSのエンジニアと初めて話して、口から泡を吹いたことを思い出します。私はその時、これまでに自分がObjective-Cでコーディングしたものについて、勢い込んで話し始めました。まるで、高校の新入生が、上流階級の生徒に対して、自分が付き合う価値のあるカッコいい人間だと証明しようとしているみたいだと感じました。 デザイナーの多くが、エンジニアとの話し合い方を実はよく分かっていないと思います。もちろん、デザイナーはエンジニアと話しますが、本当の意味で関わろうとしていません。この記事を書いた理由はそこにあります。ソフトウェアエンジニアの懸
個人的にPerlでもGoでもRubyでもコマンドラインツールを作るときに考えることの一つに以下がある。 その実装言語からライブラリとして直接呼べるインターフェースを作り、コマンドもそれを呼び出すようにする。 どういうことかというと、最近書いたgo-timeoutの場合、 % go-timeout --kill-after 5 --signal=HUP 10 perl -E "say 'Hello'" は、内部的に以下を呼び出している。 tio := &timeout.Timeout{ Cmd: exec.Command("perl", "-E", "say 'Hello'"), Duration: 10 * time.Second, KillAfter: 5 * time.Second, Signal: syscall.SIGHUP, } exitStatus := tio.RunSimp
まったく個人的なモチベーションの問題から、前回の最終更新から2年以上が経過してしまい、多くの読者のみなさんにはご心配をおかけいたしました。「プログラミングに関して調べたことや日々感じたことをメモとして残していきたいと思います。」というもともとの原点に立ち返って、あまり気負わずに、また今後も時々更新していけたらと思います。今までこのブログの主なテーマとして、JavaEEやSpringといったような、いわゆる業務開発で使われるような技術を中心としてきたわけですが、最近Springを使ったJavaの開発に(アーキテクトではなく)プログラマーとしてちょっと参加する機会があったので、その時気づいたこと、感じたことを書いてみたいと思います。 さて、皆さんはアーキテクチャやアーキテクトという言葉に対してはどのようなものをイメージするでしょうか。システムのセキュリティを確保するための方式であったり、大量の
友人から「しんぺいさん DI について書いてほしい」みたいな話をだいぶ前からされてたんだけど書く気力ずっとなかった。でも仕事の気分転換にちょっとずつ書いたやつがいい量まとまったので公開するです。たいしたことは書いてないっていうか知ってるひとにはあたりまえのことしか書いてない。サンプルコードはわたしの趣味で Scala で書いてあるが、Java が読めればなんとなく読めると思います。 DI ってなに Dependency Injection、日本語で言えば依存性の注入です。おしまい。 で記事を終えてもいいんだけど、そもそも依存性とはなんなのか、それを注入するとはどういうことなのか、なぜ DI が必要となるのかみたいな話をこれからします。 そもそも依存性ってなあに 例を出します。入力された文字列をもとにおみくじをひいて、その結果を twitter に投稿するプログラムにしましょう。 まずは普通
同じ要素に対して複数のスタイルを割り当てたとき、どのように表示されるのか? ― CSSを使っていると誰もが一度は抱くこの疑問について、『CSS完全ガイド』の著者が明快に答えます。 CSSセレクタのグループ化、クラスセレクタ、IDセレクタ、属性セレクタ、疑似セレクタなど、スタイルの指定対象となるさまざまなセレクタについて、また割り当てられたスタイルがどのように重みづけされ、評価されて表示されるかについて、"CSS: The Definitive Guide 4th Edition"(未刊行)の一部となるべく書かれたテキストを、コンパクトな分量で抽出した書籍です。なお本書はEbook版のみの販売となります。 セレクタ、詳細度、カスケード まえがき 本書で使用されている表記規則 サンプルコードの使用について 本書に関するお問い合わせ 1章 セレクタ 基本ルール グループ化 クラスセレクタとIDセ
A JavaScript pattern and antipattern collection that covers function patterns, jQuery patterns, jQuery plugin patterns, design patterns, general patterns, literals and constructor patterns, object creation patterns, code reuse patterns, DOM and browser patterns (upcoming). Patterns collected while developing 喜感网. General Patterns Function Declarations - creating anonymous functions and assigning t
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く