GoogleのShell Style Guideの邦訳 - Qiita
背景 (Background) どのシェルを使うか (Which Shell to Use) Bash は実行が許可された唯一のシェルスクリプト言語である。 実行可能ファイルは #!/bin/bash と最小限のフラグで始めなければならない。シェルオプションの設定に set を利用することで、 スクリプトを bash script_name として呼び出してもその機能を損なわないようにせよ。 全ての実行可能シェルスクリプトを bash に制限することで、全てのマシンにインストールされた一貫したシェル言語を得る。 これに対する唯一の例外は、コーディング対象によって強制される場合である。この1つの例として、Solaris SVR4 パッケージは、どんなスクリプトにも plain Bourne shell であることを要求する。 いつシェルを使うか (When to use Shell) シェル
本の紹介『読みやすいコードのガイドライン』 - ソフトウェア設計を考える
はじめに 良い本です。コードを書く人であればだれでもが気づきと学びがあるでしょう。 特に、コードの規模が大きく長期間にわたってさまざまな関係者が読むことになるプログラムを書く人にはぜひ読んでほしい本です。 gihyo.jp この本から学べるのは、どちらかというと「やり方」よりも「考え方」です。 書き方の具体例というよりは、良いコードを書くための考え方を、著者の知見に基づいて丁寧かつ具体的に説明しています。 別の言い方をすると、とにかくコードの具体例で「やり方」を覚えたい、という人には合わないかもしれません。 コードの具体例もたくさん登場しますが、それは「考え方」を説明するための例であって、コードの書き方のお手本やサンプルを集めた本ではありません。 サンプルコードはKotlinです。内容は、どちらかといえばユーザーインタフェースよりという印象です。しかし、Kotlinを知らなくてもほぼ問題な
DX Criteria (v202104)/企業のデジタル化とソフトウェア活用のためのガイドライン
DX Criteria( DX基準 )は、日本CTO協会が監修・編纂している企業のデジタル化とソフトウェア活用のためのガイドラインです。 本基準は、デジタル技術を企業が活用するために必要な要素を多角的かつ具体的に体系化したものです。ソフトウェアエンジニアリング組織の健全な成長・経営目標の可視化・パートナーとのコミュニケーションなどに使っていただくことを目的に作成されています。 また、本基準は絶対ではありません。誰かを攻撃したり、アセスメント結果の数字のみに注目して本質的な改善をおろそかにするためのものではありません。極めて実践的で具体的な項目で構成されているため、定期的に最新動向に併せてCTO協会のWG内で議論をおこないながら、適宜アップデートをしていくものです。
政府情報システムにおける 脆弱性診断導入ガイドライン
政府情報システムにおける 脆弱性診断導入ガイドライン 2022（令和 4）年 6 月 30 日 デジタル庁 〔標準ガイドライン群ＩＤ〕 DS-221 〔キーワード〕 セキュリティ、脆弱性、脆弱性診断 〔概要〕 政府情報システムの関係者が脆弱性診断を効果的に導入するための基準及 びガイダンスを提供する。 改定履歴 改定年月日 改定箇所 改定内容 2022年6月30日 - 初版決定 1 目次 １ はじめに ......................................................... 2 １.１ 目的とスコープ .............................................. 2 １.２ 適用対象 .................................................... 3 １.３ 位置づけ ...
project-guidelines/README-ja.md at master · elsewhencode/project-guidelines
いくつかのGitのルールを覚えておきましょう。 featureブランチで作業しましょう。 Why: 全作業がメインブランチではなくて独立した作業専用のブランチで完結するからです。そうすることによって混乱をきたすことなく複数のプルリクエストを作成することができます。作業途中のコードや不安定なコードをmasterブランチを気にすることなく繰り返し作れます。もっと読む... developブランチからブランチを切りましょう Why: こうすることでmasterのコードを問題なくビルドできることができ、masterはリリース用にほとんどそのまま利用できます。(プロジェクトによってはやりすぎかもしれません。) developとmasterブランチに直接Pushするのはやめましょう。プルリクエストを作成しましょう。 Why: developとmasterブランチが更新されるということはチームメンバーに
freeeアクセシビリティー・ガイドラインVer. 202104.0を公開しました - freee Developers Hub
こんにちは、freeeのアクセシビリティーおじさん、中根です。 締切が延長されたおかげで、先日余裕を持って確定申告を終わらせることができました。確定申告は概ね独力でできるのですが、紙で交付される書類やアクセシビリティーが低いPDFで交付される書類から情報を転記するところだけは相変わらず人に頼らないと突破できず、毎年残念な気持ちになっています。でも確定申告が終わると気持ちも軽くなり、気温も高くなっていよいよ春が来るなあという感じになります。 さて、それでは今回の更新内容を紹介します。 そして最後にイベントのお知らせもあります。 freeeアクセシビリティー・ガイドライン Ver. 202104.0リリース・ノート axe改めaxe DevToolsのルールに関する情報を追加 まず、freeeでも活用していてガイドラインの参考情報でも取り上げているアクセシビリティーのチェック・ツールaxeがい
Google TypeScript Style Guide
// Good: choose between two options as appropriate (see below). import * as ng from '@angular/core'; import {Foo} from './foo'; // Only when needed: default imports. import Button from 'Button'; // Sometimes needed to import libraries for their side effects: import 'jasmine'; import '@polymer/paper-button'; Import paths TypeScript code must use paths to import other TypeScript code. Paths may be r
freeeアクセシビリティー・ガイドライン — freeeアクセシビリティー・ガイドライン Ver. 202408.0-RELEASE+5.0.2
このガイドラインは、参考情報の追加や表現の改善などで、随時更新されます。 リリース:Ver. 202408.0-RELEASE+5.0.2 ガイドライン・バージョン：Ver. 202408.0-RELEASE チェックシート・バージョン：5.0.2 更新日:2024年8月20日
UXライティングとは | UXライティングガイド
UXライティングとは何か UXライティングとは、ユーザーがデジタルサービスを操作する際に必要となるテキストを書く技術です。例えば、登録時のスタートガイド、利用の流れコンテンツ、タイトル、ボタン、画面上の説明文、エラーメッセージ、通知などの言葉がUXライティングの手法に則って書かれます。サービスの中にある言葉に対して「意味が通じればいい」という思想で書くのではなく、「ユーザーがサービスを通じて体験する一連の経験を設計する」という思想で書くのがUXライティングです。 UXライティングに求められる技術とは UXライティングには、分かりやすく書く技術と、人間らしく書く技術が必要です。この二つの技術が同居することによって、ユーザーの体験を支援することができます。 分かりやすく書く技術 UXライティングの手法に則ってテキストを書く際に求められるのは、「ユーザーの気持ちに沿った文章を書く」という抽象的な
みんなで使えるデザインガイドライン「SmartHR Design」ができました｜SmartHRオープン社内報｜株式会社SmartHR
※ 2020年 9月 3日 追記 デザインシステム「SmartHR Design」がお引越し&アップデートしたため、最新情報はこちらからご覧ください。 おつかれさまです。コミュニケーションデザイングループのさめまる（@samemaru_saxo）です。 このたび、だれでも！効率よく！SmartHRらしく！表現できるのを目標とした、デザインガイドラインができました！ ▶️ SmartHR Design https://smarthr.design （2020年9月3日更新） 社外の方でもどなたでも読めるように一般公開しています。 SmartHR Design とは SmartHRでは、資料やスライド、オウンドメディア、このオープン社内報など、日々どのメンバーもばしばしアウトプットしています。中には見た目のデザインが必要なものもありますが、どれもデザイナーに依頼して作る余裕があるとは限りません
Git / GitHub を使用したチーム開発時のガイドラインを制定しました | DevelopersIO
開発時にはみなさん Git や GitHub を使うと思いますが、使い方についてチームメンバー間で微妙に認識の違いがあると進捗を妨げてしまいます。それを防ぐためにガイドラインを定めてみました。 ちなみにこれは CX 事業本部の Tech Lead のお仕事紹介第 1 弾のポストです。 この記事の英語版も書きました。 前提 CX 事業本部ではクライアントからの開発案件や自社サービスの開発をしていますが、その際に有用な（と考えている）ガイドラインです。 様々な事情でチームメンバーが変更になる可能性があり、新規メンバーの立ち上がりを支援する意味合いも込めています。そのため、開発効率をなるべく落とさずに効果的なスキルトランスファーが実施できることを主眼としています。 ガイドライン 定めたガイドラインの全文を貼ります。 3 つのセクションに分かれています。 commit 時のガイドライン avoid
スタイルガイド - Vue.js
最終更新日: 2021年5月22日 このドキュメントは、 Vue 固有の記法についての公式なスタイルガイドです。もしあなたがプロジェクトにおいて Vue を使用する場合は、エラーや有益でない議論、アンチパターンを避けるための参考となります。しかし、スタイルガイドはすべてのチームやプロジェクトで理想とは限らないと考えていますので、過去の経験や、周囲の技術スタック、個人の価値観に基づいた上で必要に応じて慎重に逸脱することが推奨されます。 ほとんどのパートにおいて、基本的に JavaScript や HTML に対する提案はさけています。セミコロンやカンマの使用の是非はどちらでも良いです。 HTML の属性に対してシングルクォートかダブルクォートどちらかを利用するかもどちらでも良いです。しかし、特定のパターンにおいて Vue のコンテキストが役立つと判明した場合については、その限りではありません
コードレビュー虎の巻 - Qiita
レビューガイドライン(Review GuideLine) ここで述べているレビューはピアレビューについての方法です。 （作業成果物の欠陥と改善の機会を探すレビュー） 「最悪を最初に」を基本としてレビューすべき、 たとえば、仕様やアルゴリズムに欠陥があるのに、typoにこだわってもしょうがないので、なにが最悪かを考え、それを防ぐための物からレビューをします。 誤りがプロダクト全体に影響し、手戻りのコストが高くつく、あるいは失敗するようなリスクがないかを考慮にいれてレビューの対象を選択します。 たとえば、基本的な初期フェーズの要求仕様や、クリティカルな決定の基礎になる仕様、使用頻度が高いモジュールなどを重点的にレビューします。 以下に書く項目はレビュアーに負担をかけないようにするのが前提なのでレビュアーに出す前にそもそもテストしたい項目です。 参考： あなたのおっしゃるレビューってどのことかし
Google エンジニアリング・プラクティス ドキュメント
Google エンジニアリング・プラクティス ドキュメント このページは、Google Engineering Practices Documentation の非公式な日本語翻訳です。元のドキュメントは、クリエイティブ・コモンズの「CC-By 3.0」ライセンスで公開されています。 Google には、あらゆる言語・あらゆるプロジェクトをカバーする一般化されたエンジニアリング・プラクティスが数多く存在します。こうしたドキュメントは、私たちが長年に渡って開発してきたさまざまなベストプラクティスの経験が集結したものとなっています。オープンソース・プロジェクトやその他の組織でも、こうした知識から恩恵を受けられるかもしれません。そのため、私たちは可能な限り、この知識を公開するように努めています。 現在、以下のドキュメントが公開されています。 Google コードレビューガイドライン (Googl
Vueを用いた開発プロジェクト用に「コンポーネント設計・実装ガイドライン」を作った話 - Qiita
はじめに こんにちは、モチベーションクラウドの開発にフリーのエンジニアとして参画している@HayatoKamonoです。 この記事は、「モチベーションクラウド Advent Calendar 2018」8日目の記事となります。 概要 モチベーションクラウドの開発チームでは2018年10月から改善期間と称して、開発に関するガイドラインやルール作りをはじめとする、様々な改善活動に取り組んでいます。 その改善活動の一環として作成した「コンポーネント設計・実装ガイドライン」を今回は説明を交えながらご紹介して行きたいと思います。 目次 Componentの粒度に関して Container ComponentとPresentational Component コンポーネントの共通化に関して コンポーネント実装時の細かな決め事 CSSに関して まとめ Componentの粒度に関して これまではフロント
iOS/Android セキュリティガイドライン - Qiita
必須: 基本的に対応が必要。何らかの要因で対応できない場合は関係者への同意をとる。 できれば：状況的に困難でなければなるべく対応する。 基本対応なし：特別な要件がなければ対応しない。 直近修正履歴(2018/11/21) [OS共通] ログ出力の対策にproguardによる方法を追記 [iOS] 通信データのキャッシュの対策に一部問題があったため修正 [OS共通] 通信の暗号化 対応要否：必須 リスクの詳細 HTTPで通信を行うと通信データが平文でネットワークに流れるため、情報漏洩の危険性がある。 対策 通信を行う場合はHTTPS(SSL/TLS)通信を利用する [OS共通] SSL証明書のチェック 対応要否：必須 リスクの詳細 通信やWebViewで行われるSSL証明書の正当性検証を無効化すると、ネットワーク管理者などにより通信経路上のデータ改竄、傍受が可能になる。 対策 試験環境で証明
フロントエンドエンジニアから、デザイナーさんに意識してほしい10のこと｜Pittan｜note
フロントエンドエンジニアとデザイナーさんは日々協力してプロダクトを作っていく関係にあります。デザイナーさんが作ってくれたものをエンジニアが素早く実現できるよう、いくつかエンジニアから意識してほしいことをまとめました。 なんでこんな話になったのか（前置きなので次の章まで飛ばしてOKです） デザイナーさんから「この画面をこんな風に作ってください」とXDやSketch、PSDなどいろいろな形で渡されることがあると思います。 僕の個人的な意見・経験ですが、いざ実装するぞとなったときに 「あれ…ここってどうしたらいいんだろう？」 と迷って作業のスピードが落ちてしまうことがとてもストレスに感じていました。できればノンストップでいきたいなあと思うわけです。 手が止まるたび、デザイナーさんに「ここってどうしたらいいですか？」と質問するのが何か新しい画面を作るときに必ず発生していました。 「（いつも聞いてる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
api-guidelines/Guidelines.md at vNext · microsoft/api-guidelines
GitHub - WebAppPentestGuidelines/WebAppPentestGuidelines: Webアプリケーション脆弱性診断ガイドライン
フリーランスとして安心して働ける環境を整備するためのガイドライン - 厚生労働省