シェルスクリプトは変数代入で = の前後にスペースを置けない！･･･の本当の理由を知ると優れた文法が見えてくる - Qiita
シェルスクリプトは変数代入で = の前後にスペースを置けない！･･･の本当の理由を知ると優れた文法が見えてくるShellScriptBashUNIXshellPOSIX はじめに シェルスクリプトの変数代入で = の前後にスペースを置くことができない理由は、検索すれば「プログラマーの君！ 勘違いするな！ シェルスクリプトでは読みやすさのためにスペースを置くな！！ という話」のような記事がすぐに見つかります。記事に書いてあるとおり変数代入とコマンド呼び出しと区別がつかないからです。それは間違いではないんですが、私はもう少し説明が足りないと感じています。そこで今回は = の前後にスペースを置けない本当の理由を解説したいと思います。 の前に皆さんにはこの話を読みながら、自分がシェルスクリプトの言語設計者だったとしたら、どういう言語仕様にするかを考えて欲しいです。なぜかと言うとシェルスクリプトの文
特定のRakeタスク内でのみ使うメソッドの定義方法
Rails内で使うRakeタスクに以下のようなものを使おうとしました。 namespace :task1 do task :do_something => :environment do foo end def foo p "task1" end end namespace :task2 do task :do_something => :environment do foo end def foo p "task2" end end namespaceで区切られているためfooメソッドは別のものとして解釈されると思っていたのですがオーバーライドされてしまいました。 特定のRakeタスク内からしか呼び出さないメソッドのスコープを限定するにはどうすればよいのでしょうか？ 特に決まった方法がないのであればtask1_fooなどのような命名規則を適用させようと考えています。
アンサー: named exportは有害なのか - uhyo/blog
こんにちは。ここ数日は、以下の記事が話題になりました。 named exportは有害だと考えられます「named exportは有害」という主張はこれまで常識と思われていたこととは異なるため、界隈のエンジニアからは否定的・懐疑的な意見が見られます。実際、筆者もnamed exportが有害であるとは1ミリグラムも思っていません。 しかし、自分と異なる意見は当然に下等・幼稚なものであるというのは筆者が最も嫌う考え方ですから、このような異なる意見を分析・理解する必要があると思い、アンサー記事という形でまとめました。具体的には、異なる意見に達する理由としては前提が異なることと論理が異なることが主に挙げられます。前提が異なることが分かれば、自分と異なる意見に至った理由を理解でき、場合によっては取り入れることもできます。論理が違うのであれば、それは瑕疵であり指摘しなければいけません。 なお、そもそ
メタプログラミングをして割に合うかの判断基準：処理を1箇所に局所化できるか - 2014-01-16 - ククログ
毎日他の人のコミットをながめる文化で生活していると、理由は浮かばないけど「ん？このコミットはなんか気になる」と感じるようになります。それは、新しいことを知ることができたコミットだったり、真似したくなるようなコードが入っているコミットだったり、なんかまずそうな気がするコミットだったり、様々です。 「ん？」と感じてコミットを見直してみても、何が気になったか自分でもすぐにわからない場合があります。そんなとき、気になったことをコミットした人に伝えるために、コミットへのコメントをまとめ始めます。「コミットした人に伝えるため」というように、他の人に伝えようとすることがポイントです。他の人に伝えるためにまとめようとすると、思いの外なにが気になったかまとまるものです。 今回は、メタプログラミングを使ってコードを整理したコミットで「ん？」と感じたときのことについて紹介します。このおかげで「メタプログラミング
Railsアプリケーションにおけるエラー処理（例外処理）の考え方 - Qiita
はじめに Railsアプリケーションを本格的に作り込んでいくと、「エラー」とは無縁ではいられません。 しょうもないバグでエラーが発生することもありますし、ほとんど不可抗力ともいえるような大規模なネットワーク障害でエラーが発生することもあります。 エラーの種類がなんであれ、エラーが起きた場合は「原因を素早く特定し、速やかに復旧させること」と「あるエラーが引き金になって、さらに大きなエラーに引き起こさないようにすること」が重要です。 エラー処理を適切に実装していれば、原因の特定や復旧もすばやくできますし、さらに大きなエラーを引き起こす可能性も少ないです。 また、ソースコードも比較的シンプルに保てます。 逆にエラー処理が不適切だと原因の特定に時間がかかったり、異常なデータがどんどん増えてさらに大きなエラーを引き起こしたりします。 ソースコードにも無駄に複雑な処理フローや条件分岐がたくさん出てきて
Fun with keyword arguments, hashes, and splats
Fun With Keyword Arguments, Hashes, and Splats You’ve probably seen this pattern before. A method has an options hash as its last argument, which holds extra parameters: def hello_message(name_parts = {}) first_name = name_parts.fetch(:first_name) last_name = name_parts.fetch(:last_name) "Hello, #{first_name} #{last_name}" end Unfortunately, you need to extract those parameters out of the hash. An
アクションゲームを爽快にする、ちょっとだけズルい調整メモ｜深津 貴之 (fladdict)
アクションゲームで爽快感を出すための、ちょっとしたズルのメモ。いろいろとプレイして見つけたやつ、思ったやつ。 ギリギリのジャンプをしたときの体験ジャンプで飛び移るとき。「ギリギリ届かない」かつ「キーを進行方向に倒している」場合、ユーザーの意図は「飛び移りたい」と類推される。キャラの座標を多少修正して、うまく飛び移れたことにする。次善策は、「壁にしがみつける」だが、爽快感は多少落ちる。 ギリギリで減速する体験走行時に「逆方向にキーをいれている」場合、ユーザーの意図は「急減速したい」と類推できる。キー入力の長さに応じて、摩擦係数をどんどん増やす。 ギリギリで踏みとどまる体験走行時にブロックから飛び出して落ちてしまうとき。「走行と逆方向にキーをいれている」場合、ユーザーの意図は「踏みとどまりたい」と類推される。よろめき演出で猶予時間を与えるか、急減速を可能とする。 ギリギリでジャンプが間に合う体
ミラティブのサーバサイドをGo + Clean Architectureに再設計した話 - Mirrativ Tech Blog
こんにちは、テックリードの夏です。 今年4月にCTOからテックリードに肩書が変わり、ガリガリコードを書くようになりました。 背景については、こちらをご覧ください。 www.wantedly.com 普段はプロダクト側の機能開発と、サーバ側の基盤開発を半々ぐらいの割合で仕事しています。 一口にサーバ側の基盤開発といっても定義が曖昧なのですが、基本的にはこんな感じのタスクをやっています。 インフラコストの最適化 不正なアクセスからの防御 障害の再発防止 新技術の導入やアーキテクチャの整備 今回はこのうち「新技術の導入やアーキテクチャの整備」の中で、サーバサイドをGo + Clean Architectureで再設計したことについてお話したいと思います。 背景 ミラティブは2015年春頃に開発が始まり、同年8月にサービスがリリースされ、2020年8月で5周年を迎えました。 その過程で組織やプロダ
Kindleは驚くほど大量のデータを収集している
Null Sweepより。 チャーリー・ベルマー 熱心な読者として、私は初代からPaperwhiteまで、何世代ものKindleデバイスを所有しており、それぞれに愛着を持ってきました。 しかし、新しいフォーマットのの悪用の可能性にも注意を払ってきました。Amazonはあなたが閲覧するコンテンツを技術的に所有しているため、彼らはいつでもそれを取り消すことができます。Amazonが顧客のアカウント(とKindle)から特定の書籍を削除するケースがありました。かなり悪いことに、Amazonがユーザ・アカウントを取り消し、購入した書籍へのアクセスをすべて削除する場合もあります。 Kindleのサービスは読書データを活用して、デバイス間でブックマークとメモを維持したり、すべてのデバイスを最後に読んだページと同期したりするなど、従来の書籍にはない機能を提供してくれます。また、Kindleで次に読む本の
PHP でどのように Exception/RuntimeException/LogicException を使い分けるか - Qiita
PHP は各種プログラム言語の中でも比較的高級な (表現力が豊かで最適な記述を選ぶのに知識を必要とする) 例外モデルを持っていると言えます。そんな PHP の例外の各区分とその使い分けを整理し、PHP の例外モデルの設計意図を考察したいと思います。 PHP例外の分類 PHP の例外は Java とは異なり、(Error を合わせると) 合計 4 つの区分に分類されます。Java には 2 区分しかありません。(PHP では Java の Error に相当するものは発生しません。PHP の Error は Java では RuntimeException の一種に分類されています) PHP Java
イミュータブルデータモデル - kawasima
CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑なルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこともあるが、システム、設計で複雑さを更に増さないようにしたい。UPDATEに着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。
メソッドの引数はオペランドのみにする原則(メソッドの引数がクラス設計に影響する) - A Day In The Life
前回に続きメイヤー著「オブジェクト指向入門 第2版 方法論・実践」で面白い原則があったのでまとめてみました(コード例はJavaで書きました)。 前提 メソッドの引数は２種類ある オペランド メソッドの操作対象であるオブジェクト オプション 操作のモード オペランドとオプションの見分け方 引数にデフォルト値を設定しておけば呼び出し側で特に指定しなくてよい引数はオプションである クラスが進化する過程においてオペランド引数は変わらないがオプションは増えたり減ったりする ※メソッド呼び出し時に引数にデフォルト値があると便利だと感じた場合やある呼び出しでは引数の指定が必要ないと感じた場合その引数はオプションである可能性が高いです。 メソッドの引数はオペランドのみにする コピー機を表す以下のクラスがあった場合。printメソッドの引数printingSize,color,numberOfCopiesは
Webアプリケーションのログに関するいくつかの考察 - Hatena Developer Blog
こんにちは、はてなでWebアプリケーションエンジニアをやっている id:polamjag です。 最近のはてなでは、若手エンジニアを中心として、いろいろな技術を見つめ直すワーキンググループをやっています。先日、id:onk も「デプロイ今昔」という記事を書きましたが、このエントリーはそのシリーズの続きで、ワーキンググループの「ログ」の回で議論したこと・話題になったことをまとめました。 Web開発におけるログを見つめ直す ログを4つの目的で分類する 目的ごとに求められる取り扱いの要求水準 いまどきのログフォーマットについて まとめ：どう実装するかを模索していく Web開発におけるログを見つめ直す Webサービス（Webアプリケーション）の運用には、多種多様なログがついてまわります。多くのミドルウェアは何もしなくてもそれなりの量のログを出力しますし、クラウド上のマネージドサービスも然りです。行
CSSのユーティリティクラスと「関心の分離」——いかにしてユーティリティファーストにたどり着いたか（翻訳） - yuhei blog
Tailwind CSS作者のAdam Wathan氏による「CSS Utility Classes and "Separation of Concerns"」の日本語訳です。翻訳に当たって原著者の許諾を得ています。 2021年10月29日に全文再翻訳しました。 この数年の間で、私のCSSの書き方は、非常に「セマンティック」なアプローチから「ファクショナルCSS」と呼ばれるものに変わりました。 この書き方でCSSを書くと、多くの開発者からかなりの反感を買うことがあります。そのため、私がいかにしてここまでたどり着いたかを説明することで、その過程で得た教訓や洞察について共有したいと思います。 第1段階 「セマンティック」なCSS よいCSSのためのベストプラクティスとして、耳にするであろうことのひとつは「関心の分離」です。 考え方としては、HTMLにはコンテンツについての知識のみを含めるべきで
[RubyTips] 頻出名詞をクラスに抜き出す - komagataのブログ
プログラミングスクールのフィヨルドブートキャンプの提出物のレビューでよく指摘するシリーズ。 メソッド名に同じ名詞が頻出する場合、その名詞をクラス名として抜き出すとスッキリすることが多い。特にそれらのメソッドが同じインスタンス変数を使ってる場合は尚更。 Bad: class File attr_accessor :permission def open # ... end def check_permission # ... end def fetch_permission # ... end def permission_characters # ... end end Good: class File def open(path) # ... @permission = Permission.new(file) end end class Permission def initializ
クリーンアーキテクチャのUsecaseはなぜControllerへ値を返すのではなくOutput PortとしてPresenterを呼び出すのか - Runner in the High
何を言っているのかと言うと、みんな大好きクリーンアーキテクチャの右下に図示されているFlow of Controlのこと。 黒線が引かれているということは、つまりUsecaseの中でOutput Portのインターフェイスを持つPresenterの関数なりが最終的に実行されるということである。 ここで湧き上がってくる疑念は「UsecaseがPresenterを呼び出さなくてもControllerに返り値とかで値を返して、Controller経由でPresenterに渡して実行しても同じなんじゃないの？」である。つまりOutput Portというインターフェイスそのものを撤廃してControllerにPresenterを使わせるアイデアである。たしかに、仮にこの方針で行ったとしても依存の方向が壊されることはない。 Software Engineeringでは同様の質問がかなり盛り上がっている
人の作ったWebアプリケーションのコードを見るときに注目しているところ - Runner in the High
普段見ているものをなんとなく書き出してみた。 インターフェイス あえてやってないとか、レイヤ的にやる必要がないというケースもある。しかし、ある程度の規模のソフトウェアには大抵インターフェイスが現れる。インターフェイスがないコードはユニットテストもないことが多い。したがって、インターフェイスが現れないコードは責務分離が行われてない可能性を感じたりする。 言語機能上インターフェイスがない動的型付け言語の場合には、ダックタイピングを意識したコードが書かれているかをチェックする。ダックタイピングでなくとも、例えばRubyだったら抽象クラスと実装クラスの分離が行われているかを見たりする。 バリデーションロジック すべてのバリデーションが、フレームワークの機能で実装されてたりしないかをチェックする。MVCとかクリーンアーキテクチャ的な実装であれば、それぞれのレイヤでどういうバリデーションをしているのか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Subclassing core Ruby class such as Hash
Q. ファクトリメソッドを主としたクラス実装で、クラスの初期化を外から隠したい - ブログ
PayPayでのDynamoDB活用事例について
