サイボウズのOSSポリシー — OSS Policy ドキュメント問い合わせ¶ oss@cybozu.com To the extent possible under law, Cybozu has waived all copyright and related or neighboring rights to OSS Policy. This work is published from: Japan.
ソシオメディア | ヒューマンインターフェース ガイドライン
ソシオメディアがまとめている、ヒューマンインターフェースをデザインする際の指針です。これらは、インターフェースデザインに関する様々な文献と、実際のデザインコンサルティングで得た知見をもとに、ソシオメディアが独自に編纂したものです。継続的に追加・更新していきます。 すべてモデルインタラクションプレゼンテーション
API 設計ガイド | Cloud APIs | Google Cloud
フィードバックを送信 API 設計ガイド コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 変更履歴 はじめに これは、ネットワーク API の一般的な設計ガイドです。2014 年以来 Google 内部で使用され、Cloud API やその他の Google API を設計するときに Google が従うガイドです。この設計ガイドは、外部のデベロッパーへの情報提供と、互いの連携作業の効率化のためにここで共有されています。 Cloud Endpoints のデベロッパーには、このガイドは、gRPC API を設計するときに特に役立つことがあり、そのような場合にはこれらの設計原則を使用することを強くおすすめします。ただし、このガイドの使用は必須ではありません。Cloud Endpoints と gRPC はガイドに従わなくても使用できます。 このガイドは、gR
Web API 設計のベスト プラクティス - Azure Architecture Center
ほとんどの最新の Web アプリケーションでは、クライアントがアプリケーションと対話する際に使用できる API を公開しています。 適切に設計された Web API には、次をサポートする目的があります。 プラットフォームの独立。 API の内部的な実装方法に関係なく、すべてのクライアントが API を呼び出すことができる必要があります。 そのためには、標準プロトコルを使用し、クライアントと Web サービスが交換するデータの形式に同意できるメカニズムを備えている必要があります。 サービスの進化。 Web API はクライアント アプリケーションから独立して進化し、機能を追加できる必要があります。 API の進化に伴い、既存のクライアント アプリケーションが変更なしに引き続き機能する必要があります。 クライアント アプリケーションが機能を十分に使用できるように、すべての機能が検出可能である
Karma - Git Commit Msg
In the repository we use and enforce the commit message conventions. The conventions are verified using commitlint with Angular config. The reasons for these conventions: # automatic generating of the changelog simple navigation through git history (e.g. ignoring style changes) Format of the commit message: # <type>(<scope>): <subject> <BLANK LINE> <body> <BLANK LINE> <footer> Example commit messa
Semantic Commit Messages
See how a minor change to your commit message style can make you a better programmer. I use a rigid commit message format, and it makes me a better programmer. feat: add hat wobble ^--^ ^------------^ | | | +-> Summary in present tense. | +-------> Type: chore, docs, feat, fix, refactor, style, or test. More Exampleschore: add Oyster build script docs: explain hat wobble feat: add beta sequence fi
Font Sizes in UI Design: The Complete Guide
UI Course UX Course LP Course Blog Tools Data Visualization Color Picker Accessible Color Generator Gradient Generator Interactive Typography Tutorial Design Hacks One of the most common questions I receive from beginning UI designers is: what font size should I use for my project? Maybe it’s a website, maybe an Android app, maybe iPhone/iPad. Ever wish someone had compiled all the rules in one pl
2017末時点での React Component 設計のベストプラクティス - Qiita
どう考えているか、というのを聞かれたので、記事に起こしておきます。個人の意見です。 Prettier を使う 気づけばコードの整形を人間がやる時代は終わりました。 細かいコーディングスタイルでレビューの時間を取るぐらいだったら、一貫した自動整形ルールを適用すべきです。 人によっては細かいこだわりがあって prettier の規則が気に食わないかもしれず、僕も最初はそうでしたが、Atomで保存する度に自動整形を走らせる prettier の強烈な開発体験によって、最終的にそれらのこだわりを全て捨てることが出来ました。 生産性を求めるなら、現時点では最優先で導入すべきものです。 React.createClass を使わない v16 で削除されたのでいわずもがな。 同様に、 createClass でしか使えなかった mixin 周辺機能も丸ごと deprecated です。 「可能な限りは」
Polyfill のあり方と Web の進化と協調するためのガイドライン | blog.jxck.io
Intro W3C の TAG から、主にブラウザ API の Polyfill に関するドキュメントが公開された。 Polyfills and the evolution of the Web Polyfill は便利な一方で、時として標準化の妨げになってしまう場合があるため、それを避けるために、 Polyfill 実装者、利用者、仕様策定者などが、どう振る舞うべきかという趣旨である。 今回はこの内容を元に、 Web の進化と協調する Polyfill のあり方について、主に「実装者」がどうすべきかに着目し記す。 Web における Breaking Change Breaking Change は、簡単に言えば 後方互換を失うことで既存のものが壊れる可能性がある変更 のことを表す。 そして、 Web における Breaking Change (Break the Web)、具体的には W
IDCFクラウドの開発チームで使っているツールなど - Qiita
IDCFクラウド開発チームで使っているツールや開発者の作業環境を紹介してみたいと思います。 GitHub まずは定番のGithub。 約100リポジトリあり、3割がプロダクション利用、7割が社内利用の用途で使われています。またプロダクションで利用されているリポジトリの過去1年間のコミット数の合計は、5,090コミットでした（2016/12/14現在）。 Githubのコミットメッセージ コミットに絵文字を使うルールになっていて、.gitmessage に凡例を記載して使っています。 $ cat ~/.gitmessage # 例 # 📝 :memo: Update getting started documentation # 🔥 :fire: Remove deprecated methods # 🎨 :art: Refactor *** for readability # # 絵
Airbnb JavaScript スタイルガイド() {
javascript-style-guide 常に気をつけたい、JavaScriptへの正しい接し方 View on GitHub Airbnb JavaScript スタイルガイド() { 元文書:https://github.com/airbnb/javascript 常に気をつけたい、JavaScriptへの正しい接し方 Note: this guide assumes you are using Babel, and requires that you use babel-preset-airbnb or the equivalent. It also assumes you are installing shims/polyfills in your app, with airbnb-browser-shims or the equivalent. 注意: このガイドはあなたがB
[翻訳] Airbnb React/JSX Style Guide - Qiita
この翻訳について Airbnb React/JSX Style Guideの和訳です。 間違っていたり分かりにくい箇所があれば、ご指摘いただけると幸いです。 Airbnb React/JSX スタイルガイド このスタイルガイドは現在一般的に使用されている標準に基いていますが、場合によってはいくつかの慣例（async/awaitやstatic class fields）が含まれていたり禁止されていたりします。現在、このガイドにはステージ3より前のものは含まれておらず非推奨です。 目次 基本的なルール クラス vs React.createClass vs ステートレス ミックスイン 命名規則 宣言 アラインメント 引用符 空白 引数 参照 括弧 タグ メソッド 順序 isMounted 基本的なルール Reactコンポーネントは1ファイルに1つだけにしてください。 ただし、1ファイルに複数の
![[翻訳] Airbnb React/JSX Style Guide - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/1254e38358c5c90719500a1b80c8ffd78476fcf7/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUU3JUJGJUJCJUU4JUE4JUIzJTVEJTIwQWlyYm5iJTIwUmVhY3QlMkZKU1glMjBTdHlsZSUyMEd1aWRlJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz0xYTY0ZTQwNmQ5MDEyYjBmY2JhNGE0OGVkNjMyMTVhMA%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB5YW1hZGFzaHkmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTI1Mzg0MjVmMjMxMDk3OTY3YzYxOTA2YmFmZDVlMTJl%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Dd9b5864c8ec3eb905404bd594cadec9c)
メンテナブルCSS
概要 メンテナブルなCSSを目指し、定義された一般的なCSSルールの紹介と、それらのルールを適用するにあたって活用できるツールを報告します。 1. 序論 CSSは記述ルールが簡素であり、少しの学習コストですぐに記述ができる手軽なツールです。 しかし、大規模なアプリケーションで複数人で開発するケース等では、見栄えだけしか考えずに身勝手にコーディングしてしまうと、 非常にメンテナンスコストがかかる負の遺産が作られてしまいます。 そのためCSSの品質を保つために様々なプロジェクトで、CSSの定義ルールが決められています。 本稿では一般的なCSSの定義ルールと、そのルールがなぜ作られたのかを合せて報告致します。 また、CSSのルールを適用するにあたって、手動・目視でルールの適用をチェックするのは非常にコストが高い作業です。 これらルールの適用を補助するツール群を、合せて報告致します。
アップストアの審査リスクを最小化する
ここ2,3ヶ月、精魂込めて開発していた“通勤中に聞ける太宰治”がアップストアでリジェクトされた。泣ける。 原因は「ブックアプリだからiBookStoreで出してね!」だった。。 もちろん、「いやいや、これは読み上げ機能とかあって、聞く事と読む事を繋げるアプリで、iBookStoreじゃできない」とか、いろいろごねて何回かアピールしたけど、無理だった。最後には、「そんなに言うならアピールボードがあるよ」と言われたけど、なかなか厳しそう。 アプリのコード自体は、次のDropboxのテキストファイル連携する本命アプリに流用するので無駄にはならないけど、それでも、結構な時間を太宰アプリのリリースに費やしたのでつらい。 アイコンだけは手を抜けないと思って、太宰のイラストとかもイラストレーターの方から購入して作成したし。アプリに入れる太宰作品の紹介文とかも書いたし。 調べてみると、最近は書籍アプリは基
『Androidアプリのセキュア設計・セキュアコーディングガイド』【2013年4月1日版】を公開しました。 - JSSEC | 一般社団法人日本スマートフォンセキュリティ協会
2022年8月29日 『Androidアプリのセキュア設計・セキュアコーディングガイド』【2022年8月29日版】を公開しました。 ・『Android アプリのセキュア設計・セキュアコーディングガイド』【2022年8月29日版】 ・「サンプルコード一式」 【2022年8月29日版】 報道関係各位 JSSEC、『Androidアプリのセキュア設計・セキュアコーディングガイド』2022年8月29日版を公開 一般社団法人日本スマートフォンセキュリティ協会 一般社団法人日本スマートフォンセキュリティ協会（JSSEC：会長 佐々木 良一）の技術部会 セキュアコーディングWG（リーダー 宮崎 力）は、2012年6月に公開した『Android アプリのセキュア設計・セキュアコーディングガイド』（以下 本ガイド）の14版目の改定版である2022年8月29日版を公開しました。 ■2022年8月29日版の改訂
ガイドラインからみたアプリUI〜iPhone用とAndroid用〜
京都まゆまろ杯 第1回スマホアプリコンテスト連動イベントでの発表資料 アプリのガイドラインを抜粋し、それぞれのアプリでどう展開するかのベーシックな知識を説明
Android アプリ品質ガイドライン
.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads
Web API 設計のベストプラクティス集 "Web API Design - Crafting Interfaces that Developers Love" - フリーフォーム フリークアウト
移転しました http://please-sleep.cou929.nu/20130121.html
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Git Commit Message Conventions
The Rules of React
