タグ

ブックマーク / qiita.com/suin (6)

  • JavaScript: 通常の関数とアロー関数の違いは「書き方だけ」ではない。異なる性質が10個ほどある。 - Qiita

    稿では、アロー関数とfunctionキーワードを使って定義される関数を区別するため、functionキーワードを使うほうの関数を「通常関数」と呼ぶことにします。英文で見かけるregular functionの翻訳になりますが、これは公式の用語ではなく、解説の便宜上のものとご理解頂ければと思います。単に「関数」というときは、通常関数とアロー関数どちらも指すこととします。 関数の歴史 歴史的に見ると、通常関数は古くからある言語機能であるのに対し、アロー関数は新しいものです。アロー関数はES2015(ES6)で導入されました。導入にあたっては、関数を短く書きたい、thisを束縛したくないという2つの理由があります。 通常関数とアロー関数の性質の違い 通常関数とアロー関数では、構文が違うというのは見て分かると思います。構文についての違いはここでは解説しません。 ここでは、文法以外の相違点をひとつ

    JavaScript: 通常の関数とアロー関数の違いは「書き方だけ」ではない。異なる性質が10個ほどある。 - Qiita
  • コミットメッセージの作法 - Qiita

    gitプロジェクトのガイドラインを参考にまとめました。この作法は英語で書くことが前提となっています。 1. コミットメッセージの1行目は短い説明文(50文字以内) モジュールについての修正の場合、モジュール名: ではじめる 説明文は小文字ではじめる 説明文のピリオド(句点)を省く 2. 2行目は空行にする そうすることで、例えばコミットした内容を E-Mail に変更するツールにて、 Subjectに最初の行を使用し、残りの行を文にすることができる。 3. 文には意味ある内容を含める 問題点: 修正した問題点について説明する 妥当性: 行った修正について、「なぜその方法がより良いのか」を説明する 代替案: もし、他の修正方法を検討したのなら、それらについて説明する 4. 変更は命令形で表現する まるであなたがコードベースに変更を命令じているかのように書く。 [bad] "This pa

    コミットメッセージの作法 - Qiita
    yggdra_w
    yggdra_w 2014/09/06
  • DDoS攻撃されたらそこで試合終了!? レンサバから利用停止を宣告される前にできる8つの対策 - Qiita

    もしも運用しているサーバにDDoS攻撃をされて、大量のトラフィックを理由にホスティング業者から、そのサーバの利用停止を唐突に宣告されたらどうしますか? なにか対策を考えていますか? by woodleywonderworks. CC BY 2.0 「ファイアウォールでそういった攻撃を防いでいるから大丈夫」「まさか契約上そんな一方的なことができるはずない」と思うかもしれません。私もそのような認識でした。しかし、実際にDDoS攻撃を受けてみると業者の対応は次のようでした。 ホスティング業者は味方をしてくれない ホスティング業者は技術的に的はずれな対策を講じる ホスティング業者は利用規約を拡大解釈し、サービス停止を迫ってくる この3点を信じられない方のために、「付録:DDoS攻撃を受けた時のGMOクラウドPublicと私のやりとり」をこの記事の最後に書いたので、現実のホスティング業者の対応が実際

    DDoS攻撃されたらそこで試合終了!? レンサバから利用停止を宣告される前にできる8つの対策 - Qiita
  • 俺史上最強のiptablesをさらす - Qiita

    #!/bin/bash ########################################################### # このスクリプトの特徴 # # 受信・通過については基的に破棄し、ホワイトリストで許可するものを指定する。 # 送信については基的に許可する。ただし、サーバが踏み台になり外部のサーバに迷惑をかける可能性があるので、 # 心配な場合は、送信も受信同様に基破棄・ホワイトリストで許可するように書き換えると良い。 ########################################################### ########################################################### # 用語の統一 # わかりやすさのためルールとコメントの用語を以下に統一する # ACCEPT :

    俺史上最強のiptablesをさらす - Qiita
  • データベーススキーマ変更の失敗しにくい管理方法 - Qiita

    プロジェクトの成長と付随して、データベースの構造は変化するものです。番環境であればプロダクトのリリース時、開発環境であればコードベースからチェックアウトしてきた時などのタイミングで、データベースの構造を変化させなければなりません。 ここでは、複数人が携わるプロジェクトにて、失敗の少ないデータベーススキーマ変更の管理方法について紹介します。 [2016-05-12 追記] この記事の内容は非常に古いものになっています。現在は「Flyway」といったDBのマイグレーションのためのコマンドラインツールがあります。このツールは、この記事で紹介する方法やRuby on Railsのマイグレーションと似た仕組みを採用しています。この記事で紹介する手動な運用に取り入れる前に、是非Flywayを検討してみてください。 Problems 下記の問題のどれかに当てはまればこの記事はあなたにとって有用でしょう

    データベーススキーマ変更の失敗しにくい管理方法 - Qiita
    yggdra_w
    yggdra_w 2013/11/21
  • 【まとめ】これ知らないプログラマって損してんなって思う汎用的なツール 100超 - Qiita

    2019/06/11追記: これは2012年の投稿です。なぜかはてなブックマークで拡散されていますが、内容は時代にそぐわなくなったものもあるのでご注意ください。 これ知らないプログラマって損してんなって思う汎用的なツールのコメントに寄せられたツールを分類分けしてみました。 解説は、ほぼコメントに寄せられた内容のコピペです。 URLのみの記述は公式サイト(か、ほぼ公式サイトと化しているサイト) 公式サイトとは別に、ページタイトルだけでツールを説明しきっているページへのリンクも付けておきました。類似ページが複数ある場合は、はてブのブックマーク数が多いものを選びました。 知らないツールもあるので、分類がいいかげんなところもあると思います。何か気づいたらコメントください。 解説が不十分なツールについても、補足(コピペで文に取り込める体裁だとありがたい)を頂けると助かります! 元ネタの投稿は現在進

    【まとめ】これ知らないプログラマって損してんなって思う汎用的なツール 100超 - Qiita
    yggdra_w
    yggdra_w 2013/06/18
  • 1