モックは必要悪で、しないにこしたことはない - blog.8-p.info
Mockito や gomock が使いやすいせいか、単体テストというのはモックするものである、という思い込みがあるのか、人々がモックしすぎているのを時折みかける。 モックは必要悪で、しないにこしたことはない。外部の API サーバーとかはガンガン叩くわけにもいかないけれど、ファイル読み書きくらいは、実際にファイルを作ったり消したりしてしまっていい。/etc/passwd を消すとか、1GB のファイルを作るとかだと難しいかもしれないけれど、その場合でも、パスのプレフィックスを指定できるようにして、一時ディレクトリの中の etc/passwd を使うとか、ファイルサイズを指定できるようにするとか、逃げ道はいくつもある。そこを飛ばして「ファイル操作は一律モックしましょう」とか頑張りだすと辛いことになりがちだ。 モックの一番の問題は、本番とテストで違うコードが走ることで、これは自動テストの価値
命名のプロセス - kawasima
多くの人が、1回で最高の命名をしようとする。これは難しく、うまく行くことなんて滅多にない。問題はネーミングというのは設計であるということだ。あらゆるものに収まりの良い場所を与え、正しい抽象化をしなくてはならない。これを最初の1回で完璧にこなせる可能性は低い。だから進化的ネーミングについて話をしよう。
さよならアーキテクチャ議論｜Seiji Takahashi@ベースマキナ
ポエム。 つまり？予算やチームのリテラシーに合わせて最速で作れて、チーム内で「俺ら高凝集低結合だなー」と思えるなら、アーキテクチャはなんでもいいと思えてきました。 前提・まだ割と収益が安定してないプロジェクトでの話です。お金があるなら好きにやりましょう。Go Bold。 ・DDDやクリーンアーキテクチャがダメとは言ってないです。むしろ自分は直近そこまで厳格ではないクリーンアーキテクチャでAPI書いてます。 ・以前こういうポスト書くくらいにはアーキテクチャのこと試行錯誤してました。 アーキテクチャ導入議論への疲労以前僕は、DDDやクリーンアーキテクチャを導入するという話が出ると積極的に顔を出すようにしていました。でも、最近は「導入しましょう」「既に適用してあるのでキャッチアップしてください」などの議論をするのに少し疲れてしまい、足が重くなったように感じます。もうおじいちゃんなので体力がないん
ノーコードは形を変えた現代のRPGツクールなのではないか
この記事について。 2030 年 「エンジニアです。コードは書けません。」｜__shinji__｜ note 自分はそもそもビジュアルプログラミングやオーサリングに興味があり、ノーコードは興味の範疇でありつつも、現状のもの、現状の「コード抜きで作れる」ような謳い文句は厳しいと思っています。それを、RPG ツクールを例に説明します。 はじめに、ノーコードを分類する 本記事では、「専用の管理画面で編集し、出力のためにコードを書かない、もしくはコピペ程度」のものをノーコードとして扱います。 その中でさらに種類ごとに分類してみます。このような定義があるわけではなく、自分の主観的で暫定的な分類です。 タイプ 1: データベースから自動的にフォームを生成 Google App Sheet MS Power Apps タイプ 2: 高水準 API のパイプライン Zapier IFTTT 古の Yaho
大規模ソースコードの読み方
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
アプリケーションにおける権限設計の課題 - kenfdev’s blog
日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
動作するきれいなコード: SeleniumConf Tokyo 2019 基調講演文字起こし+α - t-wadaのブログ
この文章は、2019年4月18日に開催された国際カンファレンス SeleniumConf Tokyo 2019 で行った基調講演の文字起こしを土台に加筆修正したものです。 当日の講演資料は speakerdeck で、動画は YouTube で公開されています。 Clean code that works - How can we go there? - Takuto Wada | SeleniumConf Tokyo 動作するきれいなコード - どうたどり着くか 本日の講演タイトルは「動作するきれいなコード - どうたどり着くか」です。動作するきれいなコードへ至る道の話をさせていただこうと思います。 資料は公開予定で、講演の写真撮影も問題ありません。ツイッター等での実況も大歓迎です。ハッシュタグは #SeConfTokyo です。 改めて自己紹介です。和田卓人（わだたくと）といいまして、
より良いコードレビューをするために気をつけていること | メルカリエンジニアリング
Merpay Advent Calendar 2019 の22日目は、メルペイスマート払いチーム/Backend Engineer の @oinume がお送りします。今日はコードレビューについて自分が普段から実践していることを書いてみたいと思います。 はじめに 世の中にはコードレビューをする時の観点については数多く共有されていますが、より良いコードレビューをするためにはどうするのが良いか、というHOWについてのノウハウはあまりシェアされていないような気がしています。そのため、今日は自分なりに心がけているコードレビューのやり方と、ついでに気をつけている観点について書きたいと思います。 Slackを閉じる (これが本当に一番大事だと思っているので最初に持ってきたのですが)私は極端に集中力がないため、SlackのDesktop通知が来るとついついそれが気になって見てしまいます。コードレビューの
"クソコード"は人格攻撃ではないのか｜qsona
これは仮説というか自分がこうだという話なのだが、自分のアイデンティティを侵食されると怒りが湧く。たとえば、自分が非常に大事にしている価値観に対して、同僚から「君のその価値観は間違っている」と言われたり、あるいは、作品とか、経歴とか、家族とか、そういう自分自身と非常に密になっていて同一視されるようなものをけなされたら、腹が立つということだ。 プログラマーにとって、ソースコードというのは一つの作品だ。仮に経験が浅い開発者であっても、あるいは経験が浅いからこそ、1行1行に時間をかけて考えながら作りあげる。それに対してこれはクソコードだと言われたらどうだろうか。考えてみる。 よく、クソコードというのはコードがクソだと言っているのであって、お前がクソだと言ってるわけではないから切り離して考えるべきだという言説がある。僕はこれには微妙に賛同できない。その人が生み出したコードは、少なくともその人のいくぶ
Takuto Wada on Twitter: "コードには How テストコードには What コミットログには Why コードコメントには Why not を書こうという話をした"
コードには How テストコードには What コミットログには Why コードコメントには Why not を書こうという話をした
付け焼き刃でサンフランシスコ・ベイエリアのコード面接を突破する方法
付け焼き刃でサンフランシスコ・ベイエリアのコード面接を突破する方法 付け焼き刃でベイエリアの面接を突破するたった1つの方法 2018年11月26日、スマートニュース株式会社にて「"GO GLOBAL" meetup#1」が開催されました。海外の活動や海外のエンジニア文化に関心のあるエンジニアが集い交流を行うことを目的とした本コミュニティ。世界各国で活躍する現役エンジニアたちが、海外におけるリアルな経験や文化を語ります。第1回目となる今回は、コーディング面接やオンラインテストについて、日本で実際に運用を開始している企業や、海外でコーディング面接を受けたことのあるエンジニアが、そのノウハウや実体験を明かします。プレゼンテーション「付け焼き刃でベイエリアの面接を突破するたった1つの方法」に登壇したのは、Daigo Sato氏。アメリカ、サンフランシスコのベイエリア転職活動をするなかで経験したこと
Big Sky :: 書評「Go言語による並行処理」
O'Reilly Japan, Inc. 様に献本頂きました。ありがとうございます。 そして献本頂く際にお声を掛けて頂いた、本書の翻訳を担当された ymotongpoo さんにもお礼を申し上げます。ありがとうございます。 本書の訳は非常に素晴らしく、とても原文が英文であったとは思えないほど綺麗で、読んでいく中で「原文でどの様に表現されているんだろう」といった引っかかりも無く、とてもスムーズに読み進められました。 Go 言語に関わって随分と長くなってきました。初めて Go を知ってからユーザがどんどん増える様を見る事が出来るのは正直に言って非常に嬉しいです。 ふと Go の魅力は何かと聞かれたら幾つか挙げる事が出来ますが、間違いなく選ぶのが「非同期処理の簡単さ」です。これまで多くの開発者が OS スレッドで実現してきた非同期処理を、Go 言語は少ないイディオムとインテリジェントなランタイムを
オブジェクト指向の呪いと、その避け方 - mizchi's blog
このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(
rechord - 演奏もできるコード進行共有サービス
rechord はコード進行を入力するだけで誰でも簡単に演奏/共有することができる Web サービスです。
シャニマスのコード読んだ - mizchi's blog
ライセンス表記みるぐらいで深掘りはしてない シャニマスのコード読むか— human eslint --fix (@mizchi) 2018年4月24日 シャニマス、pixijs ですね— human eslint --fix (@mizchi) 2018年4月24日 pixi-ae.min.js たぶん after affect のコンバータなんだろうけどググっても引っかかんないな、内製かな— human eslint --fix (@mizchi) 2018年4月24日 s/after-affect/after-effect After effects to pixi.js | CodeSeek なら見つかったが、該当のライブラリ名で探してるが見つからず パーティクルはこれ https://t.co/NtIqPBBq7n— human eslint --fix (@mizchi) 201
ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識が本になりました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない！vs. 現場に任せてくれない！の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマ
コードリーディングについて | ありえるえりあ
コードリーディングについて アリエルネットワークCTO 井上誠一郎 自己紹介 書籍 「P2P教科書」 「パーフェクトJava」 「サーバサイドJavaScript入門」 「パーフェクトJavaScript」 今回の講義 心構えや経験談が中心 抽象論になりすぎないように実践可能な「トライ」ページ 次回講義の予告 3月1日の予定 「Webアプリのアーキテクチャの歴史と進化」 専門用語多め 反応を比較して今後の講義の参考にします コードリーディング(1) 現場で重要なスキル 既存コードベースがある場合、書くコード行数は驚くほど少ない 学習と実務でのギャップ サンプルコードは短い コードリーディング(2) 既存コードを理解できないと デバッグできない 新機能の追加ができない 既存コードと同じコードを書いてしまう(無知ゆえのコピーコード) => 更に読みづらくなる悪循環 理解できないコードは悪 多少
太一のコードの読み方メモ
太一のコードの読み方メモ 全体として太一が感覚的に実践している事を論理的に説明しようと試みている為、 説明の粒度が適切でなかったり一貫性が無いように見える部分があるかもしれない。 普段やっているけども書ききれていない事も多分きっとある。 コードを読むとは何か コードを嗜む コードを学ぶ 武器を手に入れる これは武器を手に入れるコードリーディングの話 武器とは何か プロジェクトで戦う為の道具となる知識 プロジェクト内における技能を示す為の道具となる知識 プロジェクトのやり方を自ら決められる様になる為の道具となる知識 権限と責任がバランスよく割当てられた時モチベーションは最大化する 何と戦うのか プロジェクトリスク プロジェクトをより良い状態にする為の基礎的な根拠となるのがコードである コードが全てではないが適切に動作するコードが無ければプロジェクトは終わらない これはつまり理想を体現する為の
第6章 ほかの人のコードを読もう―無理なく始められるコードリーディングのコツ | gihyo.jp
コードの書きかたやコミットのしかたが大事なのはわかっても、自分で実践するのはなかなか難しいですね…… そういうときは、ほかの人のコードやコミットを見るといいよ。自分にない視点、これまで知らなかった書きかた、テクニックなど、先輩たちの良い行いを手本にすれば、良い習慣を効率良くものにできるね でも、社内のリポジトリにはすでに大量のコードがあるし、どこから読めばいいか見当も付かないです そうだなあ、じゃあほかの人のコードを多く読むためのコツもいくつか教えておこうか すべてのコードを読む 最も単純なのは、小説を読むようにすべてのコードを頭から読むというやりかたです。 この方法では、リポジトリを手元にgit cloneしたり、ファイルをダウンロードしたりして、ファイルの先頭から順番に読んでいきます。GitHub上のリポジトリやMercurialリポジトリでは「ファイルブラウザ」という機能を使ってWe
読みやすいコード（僕にとって） - Mitsuyuki.Shiiba
最近気づいたことがある。それは、僕はみんなみたいに複雑なことが理解できない、ってこと。 話をしてても「ごめんなさい。いまのわかんなかった。もう一回教えて欲しい。」とかよくあるし。ドキュメントも、ちょっと複雑なことが書いてあると、全然頭に入ってこない。 色んなルールがドキュメントに書いてあって、それをちゃんと守りながら開発してる人たちとか見てると、みんなすごいなぁって思うのであった。 なんだろうなぁ。こう・・・色んな想像が始まってしまって、考えが落ち着かないんよね。 そんな僕なのだけど、ここ数年はありがたいことに色んなコードを読む機会がある。読みやすいコードもあれば、パズルみたいに複雑なものもあって。そんな中で、たぶん、僕にとって読みやすいコード、というのは普通の人にとってはとても読みやすいコードなのかなぁって思って。書いてみる。 JavaでWebのアプリを開発してる。基盤とかフレームワーク
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
