タグ

guidelineとshに関するraimon49のブックマーク (13)

  • Makefile覚書: Goアプリ開発に役立ちそうな基礎知識 | フューチャー技術ブログ

    はじめにTIG真野です。育休明けです。 フューチャー社内のタスクランナーはmakeやTaskなど複数の流派があり、チームによって使い分けられています。個人的にはmakeで良いんじゃないかと思っていますが、Taskも良いですよね。 makeは細かい記法をいつも忘れる+調べるとC言語向けの情報が出てきて脳内変換に手間を感じたため、makeを用いてWebバックエンドアプリをGoで開発するということをテーマに、役立ちそうな情報をまとめます。 なお、今記事におけるmakeは、GNU Makeを指します。バージョンは以下で動かしています。 MakefileのためのEditorConfigMakefileのインデントはハードタブである必要があります。誤りを防ぐためにもEditorConfigを設定しておくと良いでしょう。 makeは通常、Makefileという名称をデフォルトで認識しますが、同一フォルダ

    Makefile覚書: Goアプリ開発に役立ちそうな基礎知識 | フューチャー技術ブログ
  • 社内用GitHub Actionsのセキュリティガイドラインを公開します | メルカリエンジニアリング

    この記事は、Merpay Tech Openness Month 2023 の4日目の記事です。 こんにちは。メルコインのバックエンドエンジニアの@goroです。 はじめに このGitHub Actionsのセキュリティガイドラインは、社内でGithub Actionsの利用に先駆け、社内有志によって検討されました。「GitHub Actionsを使うにあたりどういった点に留意すれば最低限の安全性を確保できるか学習してもらいたい」「定期的にドキュメントを見返してもらい自分たちのリポジトリーが安全な状態になっているか点検する際に役立ててもらいたい」という思いに基づいて作成されています。 今回はそんなガイドラインの一部を、社外の方々にも役立つと思い公開することにしました。 ガイドラインにおける目標 このガイドラインは事前に2段階の目標を設定して作成されています。まず第1に「常に達成したいこと

    社内用GitHub Actionsのセキュリティガイドラインを公開します | メルカリエンジニアリング
  • GitHub Actions 逆引きリファレンス

    1.この記事の立ち位置#自分がいつも調べていること、忘れがちな Tips や小ネタを列挙していく。そのため、網羅性は重視しない。 というのも、なにか調べていていろいろ読み漁った挙げ句、1周回って行き着くところは GitHub Actions の公式ドキュメントであり、たとえば Workflow の書き方は以下のページをよく開いている。 Workflow syntax for GitHub Actions - GitHub Docs それでも、公式ドキュメントで参照したい箇所を引っ張るための用語を知るまでに苦労することが往々にあり、この記事が、公式ドキュメントで参照したい箇所を導くための助けとなればと思い、書いていく。 2.Step と Job と Workflowの違いアレコレ#2-1.Step と Job と Workflow の違いの一行まとめ#Step < Job < Workflo

  • PHPにはエスケープ関数が何種類もあるけど、できればエスケープしない方法が良い理由

    このエントリは、PHP Advent Calendar 2021 の20日目のエントリです。19日目は @takoba さんによる PHPプロジェクトのComposerパッケージをRenovateで定期アップデートする でした。 SQLインジェクションやクロスサイトスクリプティング(XSS)の対策を行う際には「エスケープ処理」をしましょうと言われますが、その割にPHP以外の言語ではあまりエスケープ処理の関数が用意されていなかったりします。それに比べてPHPはエスケープ処理の関数が非常に豊富です。これだけ見ても、PHPはなんてセキュアなんだ! と早とちりする人がいるかもしれませんが、しかし、他言語でエスケープ処理関数があまりないのはちゃんと理由があると思うのです。 稿では、PHPのエスケープ処理用の関数を紹介しながら、その利用目的と、その関数を使わないで済ませる方法を説明します。 SQL

    raimon49
    raimon49 2021/12/21
    そもそもエスケープ関数の使い方を意識しなければならない状況を避ける、という話。たしかに。
  • Ansibleでリモートのインストールスクリプトの実行をcurlを使わずに記述する - YAMAGUCHI::weblog

    TL;DR ansible.builtin.uri でコンテンツを取ってきて ansible.builtin.shell の stdin を使って流し込む サンプル たとえばrustupのインストールは公式ドキュメントでは次のようなスクリプトを使っている rustup.rs curl -sSf https://sh.rustup.rs | sh -s -- -y これをこのまま ansible.builtin.shell に記述して実行すると warning が出ます。たとえばこういう具合にすると - name: Install rustup ansible.builtin.shell: cmd: curl -sSf https://sh.rustup.rs | sh -s -- -y 実行時にこういうふうにwarningがでます。 TASK [common : Run rustup] *

    Ansibleでリモートのインストールスクリプトの実行をcurlを使わずに記述する - YAMAGUCHI::weblog
  • コマンドラインツールを書くなら知っておきたい Bash の 予約済み Exit Code - Qiita

    上記の表の通り,Exit Code 1, 2, 126〜165, 255 は特別な意味を持ち,スクリプトやプログラム内で exit に指定するパラメータとしては避けるべきである.とりわけ,Exit Code 127 はトラブルシューティングで混乱の元である("command not found" で終了したのか,プログラム固有のエラーなのか区別できなくなる).しかしながら,多くのスクリプトが exit 1 を一般的な実行を続行できないエラーとして使っている.Exit Code 1 は Bash の一般的なエラーを含め,とても多くのエラーで発生しうるので,デバッグの時に切り分けが大変になるだろう. Exit Code を体系立てて定義する試みはある(/usr/include/sysexits.h)が,これは C と C++ プログラマー向けである.スクリプトに関しても同様な感じにするのが適切

    コマンドラインツールを書くなら知っておきたい Bash の 予約済み Exit Code - Qiita
    raimon49
    raimon49 2016/09/21
    >ユーザ定義の Exit Code を C/C++ 標準の64〜113(もちろん成功した時は 0)に限定すべきと提案している. / カジュアルにexit(1)やっちゃってるたなぁ。
  • ハードディスクの空き容量が極端に少なくなる場合の対処方法: Apple サポートコミュニティ

    Mac OS Xでは、Finderから確認できない不可視フォルダが多く存在します。そのため、Finderから確認できるファイル容量の合計とディスクの使用領域の間に数GBの差が生じますが、それは問題ありません。しかし、その差が10GBを超えていたり、使用中に「お使いの起動ディスクはほとんど一杯です」とエラーが出たがそんなに大きなデータを保存するような作業をした覚えはない等といった場合には、原因を特定する必要があります。ただ、Finderからは確認できない不可視フォルダに巨大なファイルが作成されるケースも多く、原因特定は容易ではありません。 このドキュメントには、原因特定に必要な操作をまとめています。問題解決の一助となれば幸いです。 [1] ゴミ箱を空にする ファイルやフォルダはゴミ箱に入れただけでは削除されないので、ゴミ箱にファイルが溜まっているようであれば「ゴミ箱を空にする」を実行する。

    raimon49
    raimon49 2016/01/15
    5GB以上のフォルダをリストアップ sudo du -g -x -d 5 / | awk '$1 >= 5{print}'
  • Option Table (GNU Coding Standards)

    4.10 Table of Long Options Here is a table of long options used by GNU programs. It is surely incomplete, but we aim to list all the options that a new program might want to be compatible with. If you use names not already in the table, please send bug-standards@gnu.org a list of them, with their meanings, so we can update the table. ‘after-date’ ‘-N’ in tar. ‘all’ ‘-a’ in du, ls, nm, stty, uname,

    raimon49
    raimon49 2014/12/21
    ロングオプション 対応表
  • シェルスクリプトのオプション設計ガイドライン - Qiita

    僕はコマンドラインで使うシェルスクリプトを書くことがけっこうあるんだけど、インターフェイスというか呼び出し方はとても大事だと思ってるので、そこにわりと時間をかけて考えるようにしてる。実装はいつでも変更できるけど呼び出し方を変えた時は利用者にも変更を強いるので、できれば最初から良い設計で作りたいと思っている。 そこで、僕がシェルスクリプトのオプションとか引数とかの仕様を決める上で注意していることをまとめてみた。シェルスクリプトや、その他コマンドラインのツールを作るときに参考にしてほしい。 シェルの種類は bash や zsh を想定してるけど、実装によらない話なのでどんなシェルでも使えると思う。 エラーの時に Usage (使い方ヘルプメッセージ)を表示するのはやめる エラーになった時に Usage (使い方ヘルプメッセージ) を表示するスクリプトがあるけど、やめたほうがいいと思う。例えばこ

    シェルスクリプトのオプション設計ガイドライン - Qiita
    raimon49
    raimon49 2014/05/21
    aliasから呼ばれることも考慮する。例えば判定の意味を持つオプションが両方とも指定されているなら後に指定した方を優先する。なる。
  • README のファイル名が大文字である理由 - clock-up-blog

    README のファイル名は慣習的にすべて大文字(であることが多い) GitHubプロジェクトを作るときに README を作成するオプションを入れておくと、README.md というファイルができる。それ以外の場所のプロジェクトでも README.txt や README など、ファイル名がすべて大文字になっているものをよく見かける。 なんか気持ち悪いなぁ、って思ってました。 readme でいいじゃん、と。 詳解 Linuxカーネル 第3版 作者: Daniel P. Bovet,Marco Cesati,高橋浩和,杉田由美子,清水正明,高杉昌督,平松雅巳,安井隆宏出版社/メーカー: オライリー・ジャパン発売日: 2007/02/26メディア: 大型購入: 9人 クリック: 269回この商品を含むブログ (71件) を見る 調べてみた README - Wikipedia, th

    README のファイル名が大文字である理由 - clock-up-blog
    raimon49
    raimon49 2014/05/12
    ASCII文字コード順 ただしLC_COLLATEの影響を受ける(指定していなければLANG)
  • uu59のメモ | シェルオペレーションポリシー

    なんとなくシェルに対してどういう態度で接しているのか思い出した順に書いておく。 こういうポリシーがあるからこうする、というよりも、こうなってることが多いのでこういうポリシーが背景にあるようだ、という知見をまとめた感じ。 dotfilesはこれ:https://github.com/uu59/dotfiles エイリアス なるべく使わない。これはgitのエイリアスなどについても同様。 https://github.com/uu59/dotfiles/blob/c7a44a1699ee82cc07a15d3ea1e2e516b7e17846/.zshrc#L84-L103 $ alias C='| xsel --input --clipboard' aptf='sudo apt-file search' apti='sudo apt-get install' apts='sudo apt-ca

    raimon49
    raimon49 2014/03/02
    Debian系でハマらないためにも/bin/shは避けて/bin/bashを明示する。
  • UNIX & Linux コマンド・シェルスクリプト リファレンス

    サービス終了のお知らせ いつもYahoo! JAPANのサービスをご利用いただき誠にありがとうございます。 お客様がアクセスされたサービスは日までにサービスを終了いたしました。 今後ともYahoo! JAPANのサービスをご愛顧くださいますよう、よろしくお願いいたします。

    raimon49
    raimon49 2009/08/20
    コーディングスタイル
  • 1