これだけは覚えたい、ユニットテストを書くための４つのデザイン - Qiita
もうちょっと規約的なものを「JavaでのUT作成基準を整理してみた」にもまとめてみました。 はじめに 去年、ブログの方に「ふつうのユニットテストのための７つのルール」という記事を書いたのですが、思ったより反響がありました。 あの記事で書いたのはあくまで原理・原則で、それを実現するためにはいくつかのテクニックが必要です。 特に、ああいうルールを作って「ユニットテストを書く事」を厳守するようにしても、 適切なテクニックを知らなければメンテが困難だったり、品質に寄与しなかったり、実行性能が悪いゴミが量産される可能性があります。 じゃあ、どうすれば良いかというと「最初からユニットテストが書きやすいように元のコードを設計する」ということです。 そう。まず身に付けるべきは「テストコードの書き方」では無く「テスト対象コード」すなわち「プロダクトコードの書き方」なのです。 また、ここで言ってる「最初から」
Googleの肩に乗ってShellコーディングしちゃおう - Qiita
はじめに GoogleさんがShellスタイルガイドを共有していたので、いくつか気になった点をピックアップしました。 自分のShellスタイルはかなり我流なので、自省の意味も込めてコメントも併記します。 Googleスタイルガイドの元ネタ （Python/C++/Java/Rとかだけでなくdocumentガイドなど色々あります） https://github.com/google/styleguide Shellスタイルガイド （今回はこちら） http://google.github.io/styleguide/shell.xml 本当は人間がチェックするのではなくcpplintのためXML定義なのかもですが、気にしない気にしない。 （見たところcpplintはc++だけだと思ってます） commitフックでshell系のlint走らせろっていうのが今風なのかもしれませんが、キニシナイキ
CSSのクラス名を決めるときに使うリストをつくりました
CSSは設計手法も大事ですが、どういう単語で名前をつけていくかも大事だと思っています。 個人個人でばらつきが出るところでもありますし、「単語名 英語」で検索をして探した単語を使ったけど若干意味合いが違ったといったこともあると思います。 クラス名を決めるためのリストを見かけることもありますが、英単語の読みは書かれていても意味合いが書かれていることは少ないように思います。 自分の確認用と、チームで製作するさいの基準になるようなものを作りたいと思い、単語とその意味を短くまとめてGitHubにあげています。 CSS クラス名リスト | GitHub 以下投稿時の内容です。 名前をつけることは難しいですが、とても重要なことです。 CSSには設計思想が必要ですが、実践するにあたり、名前と機能の意味がとおり、名前のつけ方にブレがないようにするべきです。 このドキュメントでは、CSSでよく使われる単語を分
Goのアンチパターン
Go書いててなんとなく見えてきた Goでやっちゃいけないパターン WAF導入してらくらくWebアプリ WAF自体が現在群雄割拠状態。 WAF毎にハンドラインターフェースが違うので既存コードつなぐにはラッパーが必要。 どのWAFもLL言語に比べるとまだまだフィーチャーの網羅範囲が狭い。 なのでもちろんLL言語ほど楽には書けないことが多い。 リフレクション使いまくりでトータル性能はLL言語並みに遅いのもある。 Go1.7のcontextパッケージの導入で標準のHTTPハンドラが復権する可能性があり更に荒れる予想。 追記: 楽できるのを期待してWAFを導入するの「やっちゃいけない」とまでは言い過ぎだったかもしれないけれど例のsqlでPrepareを正しく使えていないで性能出なかった件とか、当面WAFを使うなら自分で概ね中身を理解して使う覚悟が必要。 構造体メソッドにロジックを詰め込む Goの思想
1年後に読み直しても発狂しないJavaScriptを書く15の方法
「そのコメントわかりづらいんだよ！」なんて上司や同僚に叱られちゃった人へ。コメントがなくてもわかりやすいJavaScriptを書くテクニックです。コメントを書かなくていい、ということではないので、あしからず。 本記事はTim Severien、Mark Brownが査読を担当しています。最高のコンテンツに仕上げるために尽力してくれたSitePointの査読担当者のみなさんに感謝します。 完全に場違いで無意味なコードのコメントを書くのはつまらないと思いませんか？ 一番ありがちな間違いの例は、いくつかのコードを変更したあと、コメントの削除や更新を忘れてしまうことです。悪いコメントがあるからと言ってコードそのものは壊れませんが、デバッグ時にどうなるかを想像してください。そのコメントが読まれるとします。そこには何かが書いてあるわけですが、コードはまったく別のことを実行します。おそらく、コメントとコ
新 App Store 審査ガイドライン 翻訳&移行ガイド - Qiita
はじめに 2010年9月から公開されてきた App Store の審査ガイドラインは、2016年6月13日付けで全面的に改訂されました。これはその審査ガイドラインの翻訳&移行ガイドになります。 従来と比べて内容面に大きな差異はありませんが、継ぎ足されてきたカテゴリ群の整理や Mac App Store との統合により、構成面は大きく変わりました。記述スタイルは will be rejected の箇条書きから説明文章の割合が増えた印象。 下記では翻訳と共に新規情報を整理していますが、大半の箇所では制約が増えたわけではなく、明記されたという認識の方が適切です。翻訳部分については意訳になるため、気になる項目は原文を参照ください。なお、当資料は iOS 本執筆過程における副産物のため、iOS 以外の内容は割愛しています。 1. Safety App Store の安全性を保つために以下注意。 W
CSSの設計 – FLOCSSをベースにしたファイルの構成と命名規則を考える ｜ Tips Note by TAM
「どうやってコーディングをして組み立てていこうか？」 いくつもの案件を経験しても、いつも悩んでしまうのがCSSの書き方です。「それなら自分なりの考えをまとめてルールを作ってしまおう」と考え、CSS設計に関する情報から自分なりにコーディングルールを作りました。 今回の内容は社内勉強会で発表した「CSSのファイル構成と命名規則」の資料を再編したものです。 すべての案件内容で最適な方法ではないこともあると思いますので、1つの考え方だと捉えていただけるとありがたいです。 詳しいコードやルールはGitHub（個人のアカウント）を参照してください。「使用しているテンプレート」リンク先のstyle.scssで実際の全体の構成が確認できます。 使用しているテンプレート CSSコーディングルール CSSは影響範囲の管理が難しい CSSで難しいことのひとつは「影響範囲」を管理することだと思います。 クラスを追
テスト書きすぎ問題を避ける - Qiita
新しい職場で提案したら歓迎されたので投稿しておく。 テストコード開発方針 漫然とテストコードを書いていると、以下のような問題が発生することがある。 テストに時間がかかりすぎ、待ち時間が発生したり、テスト結果を見なくなったりする テストコードの開発とレビューに時間をかけたが、そのコストに見合う利益を得られない このような問題を避けるため、以下の方針を定める。 ビジネス上の価値に比例したテスト コードの価値をビジネスへの影響や回避方法の有無により以下のようにランク付けする。 メジャー サービスの主たる機能に影響する 再現条件が広い 回避方法がない／あっても自明でない マイナー サービスの副次的な機能に影響する 再現条件が限られる 回避方法がある トリビアル サービスには影響しない 違和感はあるが、不便を感じない 回避する必要がない 複数のランクに該当する場合、より多く該当するランクに分類する。
メンテナンス性に優れ、拡張性を備えたCSSを書くために -メンテナブルCSS
メンテナンス性に優れ、拡張性を備えたCSSを書くための「MaintainableCSS」を紹介します。 あるスタイルを修正する際に他に影響を与えてしまわないか、せっかく書いたコードが先祖帰りしないか、似たページをつくる時にコードを再利用するのに問題はないかなど、全部はもちろん個々でも非常に参考になると思います。 MaintainableCSS 以下、各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様に許可を得て翻訳しています。 メンテナブルCSSにすることのメリット 1. はじめに 2. セマンティック 3. 再利用 4. ID 5. コンベンション 6. モジュール 7. ステイト 8. バージョニング メンテナブルCSSにすることのメリット モジュール化、カプセル化 スタイルはあなたの許可なしで、他のスタイルの影響を受けません。 どんなデザインの要件でも あなたの必要
翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
iOS ヒューマンインターフェースの原則 - Qiita
はじめに iOS のヒューマンインターフェースを理解するためにはまず UI 設計の原則を定めた聖典 iOS Human Interface Guidelines を読むことから始めなければなりません。ここにはプラットフォームの特徴からデザインの原則、それぞれの部品が何のためにデザインされたのか、どう利用するのか、iOS を構成する UI の基本指針がまとまっています。 よく、『磨りガラス効果がかっこいい』『アニメーションしておくとイケてる』『ボタンは右配置の方が右手で押しやすい』『流行っているから』……などの観点によって UI の設計が決められることがありますが、そういうことではないのです。いや実際かっこいいかわいいだとかの感覚は重要なのですが、見た目が何となくそれっぽいだけでは優れた UI とは言えません。磨りガラスでも何でも必ずそこには意味があります。だからこそ HIG に書かれた思想
2016年版 フロントエンド開発フォーマット
実務でよく使うhtml,css,jsの小技をつらつらと紹介します。 ※2/11のスクーの授業中で使った資料です。 https://schoo.jp/class/1776 【オシャレCSS編】 1. transformを使って要素を変形させるワザ 2. transitionを使い、CSSだけで簡単なアニメーションを行うワザ 3. keyframesを使ってCSSだけで複雑なアニメーションを行うワザ 4. 矢印アイコンをcssだけで表現するワザ 5. アイコンをアニメーションさせるワザ 6. CSSプロパティ”filter”で画像を加工するワザ 【地味だけど使えるワザ編】 7. 今どきの、要素を上下中央寄せにするワザ 8.「flexbox」で要素を自由自在に整列させるワザ 9. Windowsでwebfontをちょっとマシに見せるワザ 10. ア
Web API設計指針を考えた｜デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ
小文字のみを使用する。 単語をつなげる必要がある場合はダッシュを利用する。 単数形よりも複数形をつかう。なお、実装がRailsの場合でテーブルの複数形が誤っている場合には、URLは正しい複数形としてRails側を修正する。（APIに実装を反映させるべきではない。） スペルミスをしない。 URLの階層は浅く保ち、複雑さはクエリパラメーターに押しこむ。 クエリパラメータ名は配列で複数渡すものについては複数形、一つだけ渡すものについては単数形とする。 ページングにはper_page、pageというパラメータ名を使用する。 と書いてきたが、ただし、RESTには必ずしもこだわらず、あくまで利用側の利便性を重要視した設計とする。 1つの作業を完結するために複数回のアクセスを必要とするようなAPIの設計はChatty APIと呼ばれる。これはネットワークのトラフィックを増加させ、クライアントの処理の手間
Android Javaでフィールドにmプレフィクスをつけるのはやめよう - Islands in the byte stream
Android Javaでは昔からAOSPのcoding style guidelineに則ったスタイルがとられることが多いようです。そのなかで、private fieldに "m" (member) や "s" (static member) などのプレフィクスをつけよ、というものがあります。 AOSP Java Code Style for Contributors | Android Open Source Project これはいわゆるハンガリアン記法の変種で、こういうやつですね。 class Recipe { private String mTitle; private List<String> mSteps; // ... } これについての態度はプロジェクトごとに様々ですが、たとえばクックパッド社のJavaのスタイルガイドでは明確に否定しています。 styleguide/
【超目玉】 エールライン アド MM/リュック/2WAYトートバッグ/ナイロン/GRY/カデナなし -qoosky.net
アイテムの詳細型番 ー カラー グレー 柄 無地 素材・生地 その他 サイズ実寸サイズ (cm) 持ち手 87 マチ 12 高さ 33 幅 31 ＞採寸について
RESTのベストプラクティス | POSTD
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
マテリアル デザインのガイドライン（日本語版）
GitHub - hail2u/html-best-practices: For writing maintainable and scalable HTML documents
api-guidelines/Guidelines.md at master · microsoft/api-guidelines
PostgreSQLアンチパターン
