Goでxxxのポインタを取っているプログラムはだいたい全部間違っている - Qiita
Goで、文字列、インターフェイス、チャネル、マップ、スライスのポインタを取っているプログラムは、書いた本人がきちんと自分がなにをしているのか理解しているのでなければ、ほぼ確実に間違っているといっていい。 Goではある種の型の値はそもそもポインタのようなものである。上記の型はどれも任意の大きさになり得るが、大きくなりうる実体のデータはヒープに確保されていて、値そのものが持っているのはそのヒープ上への値へのただのポインタ＋多少の付随的なデータにすぎない。こういった値を値渡しではなくポインタ渡しする必要はない。ポインタのデリファレンスのほうがポインタのコピーより高くつくし、余計な混乱を引き起こすだけだからだ。もしこういう値をポインタ渡ししているとしたら、そのコードはなにか深い意味があるのではなく、それを書いた人が大きな値がコピーされると勘違いしていて書いた可能性のほうがずっと高い。 文字列は2ワ
オーバーフローが引き起こした面白いバグの話｜Rui Ueyama
一度聞いたら忘れられないような印象深いバグというものがある。僕は数値のオーバーフローと聞くと必ずこの2つのバグを思い出してしまう。どちらも面白いエピソードなのでちょっと紹介してみよう。 一つ目は、初代Civilizationにあったバグである。Civilizationは文明間で戦う戦略シミュレーションゲームで、チンギスハンとかエリザベス女王みたいなプレイヤーを選んで、世界制覇か宇宙開発競争での勝利を目指すというゲームだ。 初代Civilizationにあったバグは、非暴力主義のガンジーが突然核攻撃してくるというものだった。原因は文明が民主主義を採用すると攻撃性が2下がるというロジックだった。初代Civではガンジーの攻撃性は全プレイヤー中で最小の1なのだが、ゲームが進んでインド文明が民主主義を採用すると、攻撃性がマイナス2されてオーバーフローで255になり、ガンジーがゲーム中で突如、極度に攻
ソフトウェアの互換性と僕らのUser-Agent文字列問題｜Rui Ueyama
いろいろな環境で動くプログラムでは互換性のためにその場しのぎのことをしないといけないことがよくあるけど、歴史が積み重なってくると、アドホックな技の上にアドホックな技が積み上がる喜劇的な状態になることがある。こういう問題は認識するのは簡単だが直すことは誰にもできない。まさに僕がそのような体験をしたのでちょっと説明したい。 僕は仕事としてオープンソースのlldというリンカを書いている。リンカというのはコンパイラが生成したバイナリファイルをつなぎ合わせて最終的な実行ファイルやDLLを作成するプログラムで、知らない人も多いと思うけど、何をコンパイルしても最後にはリンカが動いている。lldは既存プログラムより何倍も速くてビルドが早くなるというので最近は結構人気が高まっていて、FreeBSDなどのいくつかのOSが全面的にスイッチしようとしたり、あるいは大規模プロジェクト（Chromeや、どうもFire
RailsのObject#tryがダメな理由と効果的な代替手段（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Do. Or Do Not. There Is No Try - Object#try Considered Harmful 公開日: 2017/09/24 著者: Karol Galanciak サイト: BookingSync 原文タイトルは、よくあるヨーダのセリフのもじりです。 2017/11/07: 初版公開 2022/04/07: 更新 RailsのObject#tryがダメな理由と効果的な代替手段（翻訳） Object#tryは、Railsアプリでnil値を扱う可能性がある場合をカバーするときや、与えられたメソッドがオブジェクトで必ずしも実装されていないといった場合に柔軟なインターフェイスを提供するときに、かなりよく使われています。#tryのおかげでNoMethodErrorを回避できるのですから、これでNoMetho
Railsの太ったモデルをダイエットさせる方法について - メドピア開発者ブログ
こんにちは。メドピアのRuby(Rails)化をお手伝いしている@willnetです。最近はよくリファクタリングをしています。 今回は、最近僕がリファクタリングしている内容についてまとめようと思います。 メドピアではFat Model/Controllerを避けるために、rubocopの設定を利用しクラスの行数が300行以下になるよう制限しています*1。最近300行を超えるモデルが出てきたので、一部の処理を別のクラスに切り出し始めました。 このとき、Railsが提供している機能であるconcernsを利用すると楽に行数を減らすことができますが、それだとrubocopの指摘を回避できるという意味しかないので、なるべく委譲(composition)を利用して処理を別クラスに移していっています*2。 複数モデルにまたがる処理を切り出す Railsアプリケーションを書いていると、複数のモデルを一度
RubyKaigi2017とModule Builder Pattern #rubykaigi - トレタ開発者ブログ
サーバサイドエンジニアの中村です。先日開催されたRubyKaigi2017に参加しました。 その中で最も興味深かったセッションである The Ruby Module Builder Pattern について自分なりの理解をまとめてみようと思います。 Moduleの問題 module内でdefine_methodを使ってメソッド定義を行ったmethodに対して、そのmoduleをextendしたclass内で該当のメソッドに対して super を呼び出すことができません。 module AdderDefiner def define_adder(*keys) define_method :+ do |other| self.class.new( *(keys.map { |key| send(key) + other.send(key) }) ) end end end class Line
config/routes.rb の書き方を見直した – r7kamura – Medium
開発を手伝っている Rails アプリの config/routes.rb の書き方を見直した。 ルール以下のようなガイドラインを設け、これを守るように書き換えた。 resource(s) などの DSL の利用を避けるパスの辞書順に定義するHTTP メソッドの部分だけ特別にインデントする具体例こういう形の、素朴なルーティングがひたすらに羅列されていくコードになる。実際のコードでは数百行以上に及ぶ。基本的に1行に1つのルーティングが定義される。 MyApp::Application.routes.draw do get '/' => 'top_pages#show', as: :top_page delete '/api/applications/:applicaiton_id' => 'api_applications#destroy', as: :application get '/a
Ruby の文字リテラルについて - @znz blog
Ruby には ?a で 1 文字のみの文字列を返す文字リテラルというものがあります。 Ruby を 1.9 以降から使い始めた人には 'a' などの文字列リテラルとの使い分けや String#chr の存在意義などがわからないと思ったので、知っている範囲で歴史的経緯を説明してみたいと思います。 Ruby 1.8 以前と Ruby 1.9 以降の違い マルチエンコーディング対応が入る前の文字リテラルは1バイト文字用のリテラルで、多バイト文字は使えませんでした。 コントロールやメタは昔から使えました。 以降の実行例も含めて、実行例は 2.0 以降も同じなので、省略しています。 1.8.6 以前は未確認ですが、1.8.7 とほぼ同じはずです。 $ rbenv each ruby -ve 'p ?a' ruby 1.8.7 (2013-12-22 patchlevel 375) [x86_64-
入社からの半年間でコードレビューで指摘されたことのまとめ - 30歳からのプログラミング
実務未経験でプログラマとして入社して半年以上が経った。 コードレビューで指摘されたことを備忘録としてまとめておく。 自分なりにまとめたものなので、レビュアーが言いたかったこととニュアンスや解釈がずれている可能性はある。 初歩的な内容ばかりで我ながらうんざりする。 せっかく優秀な同僚ばかりなのだからもっと高度なことを学びたいが、こういう初歩的なことが出来ないのが俺の現状なのだから、仕方ない。 そもそもPullRequestを送ったこともなかったわけだし。入社初日は、一人でPullRequestの出し方を練習していた。 それを考えればまあ、こんなものだろうか。 当たり前のことをちゃんと当たり前に出来るようになって、早く、次のステージに進みたい。 PullRequest(PR) PRのタイトルは分かりやすいものに。必要に応じてチケットの番号なども入れる。 コミットやPRは出来るだけ粒度を細かくす
続々・リトライと冪等性のデザインパターン - あらゆる操作を冪等にする方法 - Blog by Sadayuki Furuhashi
いつも心に冪等性。古橋です。 リトライと冪等性のデザインパターンの完結編です。 だいぶ間が空いてしまいましたが！ 最後に冪等性を実装する汎用的な実装手法についてまとめていきます。 パターン６：操作ログとリクエストIDでUPDATEを冪等にする 同じIDで識別される値がUPDATEされる場合、つまりmutableである値の管理は、一般に冪等に行うのが難しい。 例えば、ユーザーごとに「最後に購入したアイテム」を更新する操作を考えてみると： 1. ユーザーAが最後に購入したアイテムをアイテム1に変更する（UPDATE） 2. ユーザーAが最後に購入したアイテムをアイテム2に変更する（UPDATE） この操作に何の対策もなくリトライを実装した場合、後続のUPDATE処理の結果を古い内容で上書きしてしまう可能性がある： 1. ユーザーAが最後に購入したアイテムをアイテム1に変更する（UPDATE）→
RubyでNull Objectパターンを使えるようにするgem「Naught」のすすめ - Qiita
Null Objectパターンの実装を支援するgemとして、Naught というgemがあるのですが、Qiitaでは、業界のjoker1017さんの 俺がGitHubでスターを付けたリポジトリ一覧 という記事ぐらいしか見つからなかったので、その使い方と有用性をざっくり説明したいと思います。 Null Objectパターン is 何？ 私も最近になって知ったのですが、 こちらの記事 NullObjectパターン によると、 あるオブジェクトが nil でなければ、メソッドを呼び出す こういうパターンが頻出する場合、obj に nil の代わりに何もしないメソッドを持つオブジェクト を格納しておく インターフェースだけ持って、何もしないオブジェクトを用意することで、 そのオブジェクトを使う側は、オブジェクトが生成されなかった場合を気にする必要がなくなる → オブジェクトの状態を意識する必要が無
コードレビューの極意。それは「自分のことは棚に上げる」こと！！ - Qiita
はじめに：コードを良くするためなら遠慮は不要 昨日Twitterに投稿した内容が思った以上に拡散されていたので、タイムラインに流れてしまわないようにQiitaにも書いておきます。 内容は上に書いてあるとおりです。 コードレビューはコードの問題点を指摘し、そのコードを良くすることが第一の目的です。 そのため、少しでもおかしいと思った部分は遠慮せずにどんどんツッコむ必要があります。 しかし、レビューする側が「これ、自分もあまりできてないんだよなあ」「お前もできてないじゃん！って言われたら返す言葉もないし・・・」などと思って遠慮してしまうと、コードを改善できるせっかくのチャンスが失われてしまいます。 「自分ができているかどうか」と「そのコードを改善すること」は、それぞれ別の問題です。 なので、レビューする人は自分のことを棚に上げてでも、コードの問題点を指摘する必要があります。 また、レビューされ
イベント駆動プログラミングとI/O多重化
Kubernetesでの性能解析 ～なんとなく遅いからの脱却～（Kubernetes Meetup Tokyo #33 発表資料）NTT DATA Technology & Innovation
Swift3のIUO(!)型から属性への変更に考えさせられたこと - Qiita
Swiftを初めてそろそろ半年くらいですが、未だに書き方のベストプラクティスを模索する毎日です。 今回もベストプラクティスがわからないケースがあったのでその一つについて書きたいと思います。 内容はOptionalと初期値についてです。 まず確認 Optionalとは Optionalとは通常の型に加え、nilも入れられる型です。 使用するときは!をつけてアンラップする必要があります。
Don't defer Close() on writable files
Update: Another approach suggested by the inimitable Ben Johnson has been added to the end of the post. Update 2: Discussion about fsync() added to the end of the post. It’s an idiom that quickly becomes rote to Go programmers: whenever you conjure up a value that implements the io.Closer interface, after checking for errors you immediately defer its Close() method. You see this most often when ma
コーディングに対する考え方を変える6つのプログラミングパラダイム | POSTD
私は時折、コーディングに対する考え方を変えさせられるような、従来と非常に異なるプログラミング言語に出会います。本記事では、その中でも特に気に入っている発見をいくつかご紹介したいと思います。 これは、先賢による「関数型プログラミングは世界を変える！」的な投稿ではありません。本記事で挙げるのは、もっと「知る人ぞ知る」的なリストです。多くの読者の方にとって、以下の言語やパラダイムは聞いたことのないものが大半だと思いますので、私が経験したように、これらの新しい概念を学ぶ楽しさを感じていただければ幸いです。 注：私は以下の言語の多くに関して最低限の経験しかありません。その発想に引き込まれたのであって、専門的知識は持ち合わせていないため、訂正すべき点や誤りがあればどうぞご指摘ください。また、本記事で取り上げていない新しいパラダイムや概念に出会った方は、ぜひお知らせください。 最新情報：本記事が r/p
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - khusnetdinov/ruby.fundamental: :books: Fundamental programming with ruby examples and references. It covers threads, SOLID principles, design patterns, data structures, algorithms. Books for reading. Repo for website https://github.com/khusnetdin
Markdown を拡張する話
Adding 'trace' to ruby Logger
Can Ruby Fibers be Concurrent?