あなたのGoアプリ/ライブラリのパッケージ構成もっとシンプルでよくない？ | フューチャー技術ブログ
2023.10.5追記: Goチームからプロジェクトの目的に応じたディレクトリ構造についてのドキュメントが公式に公開されています。 https://go.dev/doc/modules/layout Goでプロジェクトのフォルダ構成どうしよう、とググると見つかるStandard Go Project Layout。とはいえ、これはかなりコード量を増やしてしまう恐れがありますので、導入する場合のデメリットも考えておく方が良いです。 特に、プログラマーは、最初にみたプログラミング言語のフォルダ構成を親だと思う特性があり、Javaや.NETに影響されるとかなり細かくフォルダを切りたくなったり、package privateなど細かく可視性を制御しようとしたりして、なおかつ「privateのテストってどうすべきなんですか？」とか議論を始めたりもしますが、Go先生によればこれぐらいは1パッケージにフ
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
開発速度と品質のトレードオフの判断基準の合意 - Hatena Developer Blog
Webサービスの開発は、ユーザ/顧客へ価値を早く届けるため、競合より早くリリースするため、人的リソースを無駄使いしないためなど、とにかく素早く進めたいものですね。一方で、開発を急ぐあまり品質を犠牲にすればかえって価値が失われたり、技術的負債が溜まって長期的なコストが大幅に増大する可能性もあります。開発速度とプロダクト品質は基本的にはトレードオフの関係にあるのでしょう。 開発速度と品質のどちらを優先するかはプロダクトの性質や、チームもしくは会社の状況によって異なるとおもいます。この状況の認識がチームメンバー間でずれていると、チームのパフォーマンスを最大限に発揮できないばかりか、チーム内の関係悪化も招きかねません。エンジニアたちとプロダクトオーナーの間の対立のようなありがちな問題の原因の一つかもしれません。 そこで、開発速度と品質のトレードオフをどう判断すべきかの基準を明確にして、原則それに従
Forward Universal WebApps
ubb.jp で発表した Forward Universal WebApps の覚悟のトークです。
プログラミング原則一覧 - Strategic Choice
見つけた時に逐次エントリしている「プログラミング原則」カテゴリの一覧です。不定期に追加しています。プログラミング一般デメテルの法則DRY原則YAGNIKISS原則OAOOUNIX哲学可逆性曳光弾直交性契約による設計 DbCプログラマの三大美徳PIEの原則SLAPパフォーマンスチューニングの格言驚き最小の原則オブジェクト指向プログラミングパルナスの規則抽象データ型サブタイプ求めるな、命じよコマンドとクエリ分離原則オブジェクト指向設計パターン言語生成・使用分離の原則パターンの定義IOP
再利用可能なコンポーネントはアンチパターン - ジンジャー研究室
言いたいこと Webフロントエンド界隈で「コンポーネント」という言葉が蔓延していて、「再利用可能になるように設計すべきだ」という論調があるが、実際には本当に再利用可能である必要性があるまで、極力考えないほうが良い。YAGNIとも言う。 以下、現時点での考え。 ビューの階層化自体はOK ここはReactの恩恵と言っても良い気がしていて、それまであんまり明言されて来なかった「ビューの階層化」について公式で説明している点がとても良くて、開発者全員がビューはツリーになってるよねというマインドで統一できた功績は大きいと思う。 再利用可能なコンポーネント ビューはツリーでいいんだけど、それをコンポーネントと呼んでいるのでなんとなくDatePickerとかTextEditorみたいな汎用的なものを想像して、「アプリケーションの事情を知っていてはいけない」という気持ちになって疎結合に作りたくなってしまう。
React + ReduxではないSPAフロントエンド事情 - Re.Ra.Ku tech blog
丸山です。 弊社も最近はiOSアプリやAndroidアプリだけではなく、いわゆるSPAなWebApplicationを開発しています。 SPAを採用した背景 その背景には サーバーサイドで複雑なビジネスロジックを実装することになるので、サーバーサイドはScalaを利用したい ScalaでHTMLを吐いてもいいのだけれど、そういうのは動的型付け言語のほうがやっぱり楽な気がする だったらScalaでJSONを喋るAPIだけ作ろう そのAPIと喋ってwebのユーザーインターフェイスを実現する部分はRoRにするか？ それともいっそSPAにしてブラウザから直接APIとコミュニケーションすればよくないか？ と、いろいろ考えたところで、まずは社内向けのツールで技術検証も兼ねてSPAでScalaなAPIとコミュニケーションするのを試してみることにしました。 まだまだ開発中なのですが、意外とうまくいっている
JavaScript Plugin Architectureというプラグイン設計について学ぶ無料の電子書籍を書いた
JavaScript Plugin ArchitectureというJavaScriptのプラグイン設計についての電子書籍を書きました。 この書籍はJavaScriptのライブラリやツールにおけるプラグインアーキテクチャについて見ていく事を目的としたものです。 以下の形式で読むことができます。 Web版 PDF形式 ePub形式 Mobi形式 GitHub上にソースコードも公開されているでので直接Markdownファイルを読むこともできます。 MarkdownよりはWeb版の方が見やすいのでそちらをオススメします。 Twitterのハッシュタグは#js_plugin_book 更新情報はRSSやリリースノートから見ることができます。 v1.0.0 最初に書くと決めたプラグインアーキテクチャが揃ったので1.0.0としてリリースしました。 JavaScript Promiseの本の時と同じく、継
【JavaBeans】BeanとDTOとEntityとVOとFormの違いって何？- Javaプログラマーのはしくれダイアリー
色んなシステムに携わっていると、様々なJavaのクラス名に遭遇する。 ○○Beanとか ○○DTOとか ○○Entityとか ○○VOとか ○○Form。 ここらへんって 「MVCのModelのデータ部分にあたるって意味で同じだし」 とか 「ゲッター/セッターがあるクラスで意味的に一緒じゃない？なんで色々名前つけてんの？」 って思いませんか？ ってことで、今回はそれぞれの定義を改めて考えてみようと思う。 とりあえずはそれぞれの意味から ・Bean 総称はBean。あえて言うならJavaBeansの略。 Javaの初心者でも知っている。 あまりに有名すぎるが、Oracleのサイトのガイドを見ながらパクってまとめてみた。 ・Sun Microsystems社のJavaBeans仕様に準拠した再使用可能なソフトウェア・コンポーネント。 ・最低限、クラスにはプロパティが必要。 ・プロパティはメソッ
アプリの外側とのやりとりをModelから取り除く - ✘╹◡╹✘
変更前 これはクライアントサイドのアプリケーションの例で、Modelの背後でWeb APIやonpopstate/pushStateを利用しており、Modelが太くなってる様子。 HTTP History | ^ | ^ | | | | v | v | .---- View <-- M o d e l <-- Intent <--. | | `----------------> DOM -------------------' 変更後 Web APIもonpopstate/pushStateもアプリケーションの外側にあり、DOMと同レイヤに存在するものであると位置づける。アプリケーションの外界とのやりとりを行う、ビジネスロジックを含まないアダプタを、ドライバーと呼んで抽象化する。ドライバーには入力を受け取る機能と出力を購読させられる機能がある。いまつくってるアプリでは以下の2つのドライバー
[ 技術講座 ] Domain-Driven Designのエッセンス 第1回｜オブジェクトの広場
DDD難民に捧げる Domain-Driven Designのエッセンス 第1回 ドメイン駆動設計とは 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関する解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無かったと言ってもいいでしょう。Eric Evansの『Domain-Driven Design』（以降DDD）は、「
PHPUnitのモックで設計とリファクタが捗る | 48JIGEN *Reloaded*
class TwitterClient { public function tweet($message) { return true; } } $hoge = new TwitterClient(); $hoge->tweet('大心なう'); // trueが返る class ClientContainerTest extends PHPUnit_Framework_TestCase { public function test_モックを書いてみる() { $hoge = $this->getMock('TwitterClient', array('tweet')); $hoge->expects($this->any()) ->method('tweet') ->will($this->returnValue(true)); $hoge->tweet('大心なう'); // true
コードレビュー - hitode909の日記
コードレビュー，慣れるとできるけど，いきなりdiffを渡されて，どうぞ見てくださいと言われてもよくわからないと思う． やりましょうというのはいいけど，ただむやみに読んでもうまくいかない．変更がある程度大きくなるとdiffだけ見てもよくわからないので，いろいろ見ることになる． 僕はいつも以下のようなことを無意識にやってて，うまくいってる気がしてる．GitHubのPull Requestの仕組みを使ってる前提で． Discussionをさらっと眺めてどういう問題を解決したいのか見る Commit Statusを見て，テスト通ってることを確認する Commitsタブで1コミットずつブラウザの新しいタブに開く 全部クリックし終わったら古い順に1コミットずつ読む 気になる点があったらエディタとかにメモしておく．あとで書き直されるかもしれないので，まだコメントしない 全コミット見終わったらFiles
OSSの開発モデルを、そのまま社内に持ち込むのは止めたほうがいい（もしくはコードレビューの話） - kazuhoのメモ置き場
以前以下のようにツイートした話だけど、OSSの開発モデルを社内開発にそのまま持ち込むのは危険。 チーム開発の場合、簡単にコメント返せないようなPR送られた時点で負けだと思ってる。無駄なコードが生産されないよう事前に設計を詰める作業をすべき / “雑なレビュー - ✘╹◡╹✘” http://htn.to/by5or1 https://twitter.com/kazuho/status/431602421068877824 今日一般的に想定される「OSSの開発モデル」はEric S. Raymondの有名なエッセーである「伽藍とバザール」によって解説されたところの「バザール」である。 「バザール」モデルにおいては、多くの改善提案の中から最善と考えられる実装が取り入れられ、コミュニティで共有されるようになる。同エッセーから引用するなら、 ふりかえってみると、Linux の手法や成功の前例は G
些末なコードレビュー - naoyaのはてなダイアリー
朝起きて布団から出るのがつらいので、HBFav をつらつらと眺めていた。 あるサービスの JavaScript が重いとか、そのコードが難読化されてないとか、担当者とおぼしき人間が書いたコメントがそのまま残ってるから消しましょうよとか、そんなことが書かれていた。JavaScript が重い、という話は結局そのサービスの JavaScript が重かったのではなく、ユーザーが自分で導入した広告が重いというだけの話だった。 コードが難読化されていない、趣味の製品ではなく会社の製品なのでコメントそのまま残ってるから消しましょう･･･実にくだらない。 ところで話は変わってコードレビューについて。 コードレビューに慣れないチームが、何の考えもナシにコードレビューを始めるととにかく気になったこと大小様々な指摘が行われることになる。一見、いろいろな指摘が出て議論が活発になっているように見えるが、だいたい
ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change!
「プログラミング経験のない人がソフトウェアの設計をすること」の是非について、どう考えますか？ もしかしたら、このブログの読者であれば、プログラミングが出来ないのにソフトウェア設計をするなんてありえない！という意見の方が多いかもしれません。私もそういう意見ではあったのですが、色々な人と話をするにつけ、どこか違和感を感じていました。 その違和感の正体を探るべく、ソフトウェア設計とプログラミングについて考えてみました。そこでわかったことは「ソフトウェア設計」について、人それぞれに捉え方が違うために、話が通じないことがあることから産まれた違和感だったということです。 この記事では、私の考える「ソフトウェア設計とは何か」について書きました。 ソフトウェア開発はすべてが「設計」である モノづくりにおいて、大きく工程を２つに分けるとしたら「設計」と「製造」に分けることが出来ます。何をどう作るかを決めるこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Real World PlantUML
基礎から学ぶ無線LANの設定と設計