(Rにおける)パイプ演算子についての個人的見解 - Qiita
R のパイプ演算子について批判的に書かれたブログのポストを見つけて、コメント欄まで含めて面白く読んだ。 My aversion to pipes 上記の記事を読んでの感想もといポエムである。 F#のパイプ演算子|>を模して(私はF#は書いたことがないのであまりわからないが)magrittrパッケージによってRに導入されたパイプ演算子%>%は以下のような書き方を可能にする。 seq(length(x)) # あるいは . <- length(x) seq(.) # ↑を↓のように書ける x %>% length() %>% seq() まあこんなに短いものだと大して旨味もないが長ったらしい例はリンク先の記事にもある。 リンク先の記事の著者が問題にしているのはどうやら パイプ演算子はNSEを使っているが、それは予想もしないような結果をもたらさないか？ パイプスタイルに馴染みのない人々もいるのに
ユニットテストの定義と価値とリスク - Qiita
特にインテグレーションテストとユニットテストの境界が秀逸であり，「インテグレーションテストは，私たちが変更できないコードに対して，書いたコードが機能するか？」ということが明言されています．実例として想像しやすいのが，データを保存する機能を持つクラスだと思います．いわゆるRepository Patternを用いたクラスであったり，ActiveRecordのようなDBと密結合しているようなクラスにあたります．このようなクラスはユニットテストはできず，インテグレーションテストを行うほうがベターです．逆にユニットテストは「私たちが変更できるコードに対して，書いたコードが機能するか？」をテストすることになります． 角の立つ言い方かもしれませんが， 関数の引数にフレームワーク固有の型を使った時点で一切ユニットテストができないと思ったほうが良いです．また，そのようなフレームワーク固有の型を使った関数を
ユニットテストを書く上で守りたいこと - Qiita
背景 普段、業務でユニットテストを書いたり、レビューをしたりしています。 ユニットテストがあることは良いことなのですが、困ったことがあります。 それは、ユニットテストのルールが明確じゃない点です。 そのため、人によって、ユニットテストの書き方がマチマチで、なんとかしたいなと困っています。 １つのテストケースに、Assertが複数あり、散在している。 似たようなテストデータの構築が、いろいろなテストケースにある。 テストする関数名が、パット見よくわからない。 本記事では、ユニットテストを書く上で守ってほしいことをピックアップしました。 守って欲しいこと 1. 可読性のあるテストコード 1.1. テストメソッド名の統一 テストメソッドの命名規則は、あったほうがよいです。 テストランナーツールの実行結果では、関数名を表示されることがあります。 そこから『どういうテストをしていたのか』が読んで分か
自動テストを書くとき、書かないとき。テスト駆動開発をバズワードとして受け取らないために - Qiita
今更テスト駆動開発がバズワードと言われるのも、結構時間が経ってるから違う気もするけど。 バズワードとして受け取られるテスト駆動開発 自動テストって大事なんだけど、バズワードと感じてしまうのは、大事さが独り歩きして、踏み絵やチキンレースみたいになっている感じがするとき。 「えwwwwwww テスト書いてないの？ 開発者として終わってんじゃん。うちのシステムはめっちゃCI動いてるけどね」 「最近テスト駆動開発はじめたけど、マジで良いわ。単体テストからめっちゃテスト書いてるから、ちゃんとしてる俺マジエンジニア」 こういうこと感じのニュアンスでマウントをかけられると、イラッとする。そう言ってるあなた、どれほど仕事でテスト書いてるんですか、って思うし、テスト書く文化が形骸化していきそうな雰囲気を感じる。 なんでテストを書かない時があるか 書けばいいじゃん、その方がエンジニアっぽいしって言うだろうけど
ChatGPTとデバッグ：落とし穴から抜け出す方法 - アイソモカ
プログラミングの9割はデバッグだ。いや、さすがにそれは言い過ぎか。それでも、デバッグ（うまく動かないプログラムを修正すること）がプログラミングの大切な一部であることは間違いない。先日SNSを見ていたら、ChatGPTをプログラミングに活用することについて「うまくプロンプトを与えても、生成されたプログラムが自分の要求仕様通りになることはまずなく、自分で修正する必要がある」と言っている人がいて、ちょっと驚いてしまった。自分で修正するなよ、ChatGPTに「思い通りに動かない」と説明して直してもらえばいいのに。 でも、考えてみると、公開されているChatGPTの使い方（プロンプト集や活用事例）は、仕様を説明してプログラムを書いてもらう方法や、アーキテクチャに関する相談……デバッグ以外の部分が圧倒的に多い。 ChatGPTにデバッグの相談をしないなんてもったいないと思う。私は趣味のプログラミングプ
プログラミングの入り口として自動テストは有効か - マンガ・ロジスティクス・エフ
毎週、Twitter SpacesとDiscordで交互にテスト自動化の話をしながらランチを食べる会というのをやってるんだけど、この中でプログラミング経験の無いテスターが自動テストを覚えるのはプログラミングの技術を学ぶ上で有効かという議題が盛り上がった。 その場で出た意見は次のようなもので、概ねハードルが高いという意見で共通していたと思う。 自動テストは開発技術を転用したものなので、普通に開発スキルが無いと厳しい 自動テストだけ覚えてもプロダクトの品質向上には寄与しないことが多い 自動テストライブラリのシンタックスを覚えただけでは足りず、一般的なプログラミングスキルは当然必要になる 初めてのプログラミングの対象がブラウザなのはつらそう 自動テストはマイクロサービスとして捉えたほうが良い 以下は自分の意見。 モチベーションの重要さ プログラミング経験が全く無い人が、自動テストからプログラミン
『プログラミングの心理学』を読んだ - 夜は寝る
在宅の日々、だいたいラジオをきいて過ごしている。radikoだけでは飽き足らず、この世のすべてのラジオアプリをインストールし、Podcastをダウンロードし、耳から注入している。 shop.nikkeibp.co.jp 先週読んだCode Completeにおいて、複数の章で参考図書として紹介されていた。著者はGerald Weinberg氏で、ソフトウェア界における偉人の一人。著作では『ライト、ついてますか』も有名っぽい。 初版はなんと1971年。磁気テープを用いた開発や、プロジェクト例などは歴史を感じさせる。本筋であるプログラマの心理面の問題意識や実験結果、考察は、いま読んでも古さを感じない。そのこと自体が、本書のテーマが本質的な問題であることを示唆している。一方、プロとアマチュア、マネージャとプログラマ、また（職業人としての）男性と女性を区別した記述がやや軽薄に感じた。これは著者の不
車輪を再発明しよう - モジログ
ウィキペディア - 車輪の再発明 http://ja.wikipedia.org/wiki/%E8%BB%8A.. ＜車輪の再発明（しゃりんのさいはつめい、英: reinventing the wheel）は、車輪を題材にした慣用句であり、世界中で使われている。「広く受け入れられ確立されている技術や解決法を知らずに（または意図的に無視して）、同様のものを再び一から作ること」を意味する＞。 ＩＴの世界では、この「車輪の再発明」という言い回しがよく使われる。すでに有名な方法やライブラリなどがあるのに、それを知らずに、あるいは無視して、似たようなものを独自に生み出す、ということに対して使われる。 「車輪の再発明」は、基本的に否定的なニュアンスをもっていて、「車輪を再発明すべきでない」という意味を含んでいる。しかし私の経験では、「車輪を再発明したほうがいい」場合もけっこうある。 既存の「車輪」が、
バグを見つけ出すのに効果的な「説明メソッド」について
元ネタはプログラミングに関するものだけど、 プログラミングに限らず広い範囲に使えるメソッド発見。 WEB+DB PRESS vol.38「プログラミングの光景」(高林 哲)の中で 「バグの原因を見つけ出すにはこんな方法があるよね」 というのがいくつか挙げられていた。 その中で「そうそう、そうなんですよね」と激しく思ったのがこれ。 身近な人に相談する（説明しているうちに自分で原因に気づく） ある。 言うことを聞かないプログラムについて人に状況を説明していて 「ここでね、ほらちゃんと中身を置換してるはずでしょ、 なのにね、なぜか表示してもね、置き換わってない・・・ のは、二次元配列になっちゃってるからですね。」 と一方的に解決してしまうことはよくある。 これは何もプログラミングに限ったことではないように思う。 パズルをやっているにせよ人生の方向性に悩んでいるにせよ 自分でいくら考えてもどうにも
ライブコーディングで GitHub Copilot を使うべきかどうか - TechとPoemeの間
TL; DR 場合による "How to" を教えるライブコーディングの場合は、切ったほうが良い 設計議論を中心に行うライブコーディングの場合は、使うと良いことがある 文脈 最近の仕事の中で、プログラミングを学んでいる人々の前で、オーディエンスのスキルアップを目的としたライブコーディングを実施したり、ライブコーディングセッションのアレンジをしたりファシリテーションをしたりしている。少々性格の異なるライブコーディングを数パターン行うなかで、「ライブコーディングで GitHub Copilot を有効にするべきかどうか」という問いに答えるに当たって一つの指針が見えてきたので書き残しておく。 How to を教えるライブコーディングでは Copilot を切る 自分が担当したライブコーディングは、特定のテスティングフレームワークの使い方やテスト駆動開発の講義だったのだけど、このような「特定のツー
固有名詞をつけるとき - 詩と創作・思索のひろば
ソフトウェアエンジニアリングにおいて大切なのは、人間のことをのぞけば名付けだと思っている。言葉がなければ世界は混沌としたままだけど、そこに名前をもたらすことがものごとを切り分け、ひとつの秩序をもった視点をつくる。この秩序は唯一絶対のものではなくて、なんらかの意志によって導かれたものである。ソフトウェアはあくまでも現実の抽象だから、問題をどういう視点で見るか、という軸があるわけだ。そういう意味では人間のことではある。 適切につけられた名前は、そのことによって他のものとの自然な境界を与えられていて、その他の名付けと一貫性を持っている。そういう名前は既存の名付けの体系になじむので、同じ言葉を使う人々のあいだに受けいられれて、共通のコンテキストに追加される。そして次第に暗黙のものになっていく。 たとえばユーザのフォローがあるSNSのようなウェブサービスをつくるときに、QueueとかBrokerみた
次第に腐るテストコード - Fly me to the Luna
結論を最初に書くと、 テストコードを書くだけではダメで、デイリービルドなりCIしないと意味ないんじゃないっすか？という事です。 最近Hudsonを使っていてすごいいいなぁ、と思うのがこの画面。 「リグレッション」という表現はすごい的を射ているなぁ、と思います。以前は「失敗」となっていたと記憶しています。 なんで的を射ているかと思ったかと言うと、テストコードって回帰テストの中で動かされると、その結果は「成功」と「失敗」だけではありませんよね。仕様変更による影響がテストコードので、テストコードが失敗すると言う事もある訳で。確かid:hyoshiokさんのブログだったかで拝見したかなんかだったんですが、Oracleでは毎朝デベロッパが出社すると、QA担当の人から失敗した回帰テストが回覧し、デベロッパに「これは障害なのか、仕様変更による影響なのか」を判断してもらった、と言う話を目にしました。テスト
失敗した分だけしか経験値が上がらない
1.失敗した分だけしか経験値が上がらない 2.近道した人の実力の危うさ 3.ネットで見かけるすごい人は、アイドルと一緒 4.あれも、これも手を出さないで、我慢する 5.心が折れるのは、みんなそう やり方が間違ってるのではないか？という疑問は、学習時間が百時間とか超えてからの話。 語学でも資格でも、学習時間に依存することは統計でもわかっています。 ずーっと同じやり方では非効率だけど、百時間やってみて、やり方を見直すというのは有効だと思います。 ただ、何もやらずにやり方を見直すというのは、指導者がいない限り、周りに参考になる現実の人がいない限り無理だと思います。 1.失敗した分だけしか経験値が上がらない 自分に必要な情報と、覚えなくてもいい情報の取捨選択が出来ていない。 膨大な情報に目を通して、「あれはやっておいた方が良いのか！」と時間を取ってしまう。 「ある程度」のレベルに達すれば、必要な知
「知っている」のレベル感の大切さ - novtan別館
僕は業務プログラマーであれ、新人のときに最低でも１日はCASLでもいいからアセンブラ的なものに触れて、高水準言語のありがたさをかみ締めながら業務に励んで欲しいとおもったりするのです。実地体験は大事。 レジスタが、「記憶領域の一種で、特に高速であり、容量の少ないPCに内蔵されているもの。」であるのは、後半部分が大いに間違っている。もちろん、高速な記憶領域、というのは正しくもあり、間違ってもいる。「高速な」は実装としてそうであることがほとんどというだけで、定義の対象ではないからね。でも実態としては、そうである。 そして、この説明は、レジスタがどういう機能を持っているかということをほとんど説明していない。 Cプログラマが、Javaを学んでクラスのことを「あれか、構造体の親玉みたいなモノか」と評したとき、一抹の不安を覚えることがある。相手が事の本質を一言で言いあわらそうと試みるとき、内容としては不
コメントを書かない理由 | おごちゃんの雑文
コードにコメントを書かない事を責められた時の言い訳 私はコードにコメントを書かない。それは面倒だとか、ここに書いてある事情があるとかではなくて、「信念」として書かない。書くべきではないと思っているからだ。コメントを書いたら負けだとさえ思っている。これはもう20年来そうだ。 ちょっとしたメモのようなコメントは、つい書きたくなる。私は「自分のコードは他人も見る」「過去の自分は他人」と思っているので、その時の助けになるようなコメントはむしろ入れたい欲求にかられる。コメントで意思伝達しておけば楽だと思う。が、「コメントを書いたら負け」だと思っているから書かない。 例外的に書くのは、 ファイルの冒頭に書くGNUなヘッダ ヘッダファイルに書く構造体の宣言 コメントアウト くらいで(これらはむしろ積極的に書く)、その書かないっぷりは、gotoよりも少ないくらいだ。 なんでそこまでコメントを嫌うかと言えば
入門書の出来の悪さとプログラム学習の難しさ
自分はObj-CやFoundationライブラリを良く知らないけれど、ちょっとした書捨てアプリをSwiftで作りたい、と思っている。 そこで、簡単なfileの読み書きをしたりするレシピ集みたいなのが欲しいな、と思い本屋でSwift本を立ち読みしたらろくでもなかった、という話。 ほとんどの入門書がろくでもないのはSwiftに限った話じゃない。ただ自分が入門書を読む事自体がもはや滅多にないので、今回久しぶりにその酷さに驚いた。 なお、レシピ集みたいなのは地元の小さな本屋には無かったが、これは要求がマニアックなので仕方ない気もする。 で、入門書が酷い。 まず、Swiftの入門書は結構数がある。 でも全部内容が一緒。 Swiftの文法を解説して、最後になんかiOSのアプリを作って終わる。 最後に何か作るのは、大抵はiOSのフレームワークにいかにも沿ったような物で、アプリを作る解説というよりはGUI
将来を想定して実装してはいけない - akiyan.com 管理人メモ
将来の実装を想定して拡張可能なように開発するのはよいことだが、 将来の実装を少しでも先取りして実装してしまうことは絶対にしてはいけない。 設定値を書いておくとか、そういうこともしてはいけない。 なぜなら、先に書いておくことのメリットはほとんど無く、 想定が外れたときの修正コストやモチベーション低下などのデメリットはばかでかい。 要するに、リスクに相応したリターンが得られない。 メリットが無いというのは、最近の生産性からいうと、先にちょろっと書いたくらいで得られる差は限りなくゼロに近いから。 仮に想定の実装がうまくいったとしても、最高の実装ではないことが多い。必要なときに、最高の実装をするのがいい。 以上、自戒でした...なんでやっちゃうんだろうなあ...。
プログラミングにおける「勘」とその鍛え方 - ぷらすのブログ
チーム開発でレビューをしていると、「パット見は問題なさそうだが、なんかバグってそう」と感じることがあります。 これは全く理論的な気づきではなく、直感的な「勘」なのですが、意外と精度良くバグを発見できることが多いです。[^1] [^1] 勿論杞憂である場合も沢山ありますが ある時、友人に「そういう勘ってどうやって鍛えるんですか？」と聞かれました。とっさに「経験かな。」と答えたのですが、確信があるかと言われると微妙です。「どういう経験を積めばいいのか？」と聞かれると答えられなかったと思います。 最近、改めてこの話題について考える機会があったので色々考えてみたのですが、「良いコードを読んだ回数に比例して勘が冴えるようになる。」 という結論にたどりつきました。 このブログでは、その結論に至るまでの思考をメモしておこうと思います。 他のクリエイティブな作業との比較 まず始めに、このような勘が他のクリ
コード書き仕草 - Object.create(null)
たまには雑談っぽいことでも書くか〜 他の開発者のためにコードを書く コードを書くにあたっての話題は尽きることがないです. ざっと思いつくようなことを挙げてみるだけでも, 性質 可読性 柔軟性 堅牢性 変更容易性 原則 驚き最小 DRY SOLID 道具 コーディングスタイル 設計 契約 テスト 型 ドキュメント などなど. ところでこれらが何のために存在するか考えたことがありますか? もちろん最終的にはユーザーにとっての価値を産むということなのですが, コードの書き方自体が直接ユーザーの価値になることはないです. まあほぼ絶対にない. 私は他の開発者のためだと考えています. コードの書き方を工夫することで, 他の開発者が価値を提供するのに役立てば良い. これは単純に私の性質の問題もあって, 元々そういう裏方的なコードを書くのが好きなのもあるし, 必ずしもユーザーに価値を提供することに興味が
「コピペプログラマ」を撲滅する必要はない | おごちゃんの雑文
ちょっと古いエントリらしいがTwitterのTLに流れて来たので。 量産型プログラマを撲滅したい 頭のいいプログラムの出来る側の人の言いそうなことである。 言いたいことはよくわかるし、昔そう思っていたこともないわけではないが、今はその必要は全く感じてない。 なぜそうかと言えば、「そーゆーもの」というドメインが明らかに存在しているからだ。 SIerの現場で書かれるプログラムに「難しい」ものはあまりない。SIで大変なのはシステム設計であり、円滑な実装(=プロジェクトの進捗)である。ここで書かれる「プログラム」の多くは退屈な同じようなロジックがほとんどである。 私がまだ新米のシステムエンジニアだった頃、システム設計の他に実装もやっていた。当時なので、コーディングシートに書いてパンチ屋さんに出して、それを計算機に入れて以降は端末で… というフローであった。その時に気がついたのは、 シーン(画面)は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
