https://github.com/soutaro/querly Rubyを構文解析したASTに対して独自DSLでパターンマッチ&メッセージを出すツール プロジェクト固有の事情に配慮したLinterとして使える false positive 上等で注意喚起として使う たとえばKibelaの querly.yaml から一部抜粋するとこんな感じです。 rules: # ... - id: kibela.order_by_string pattern: - "order(:dstr:)" - "where(:dstr:)" - "find(:dstr:)" - "exists?(:dstr:)" message: "文字列によるSQL構築は本当に必要ですか? SQL Injection を引き起こさないように気をつけてください。" - id: kibela.block_call patter
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 以下はThe Mistakes I Made As a Beginner Programmerの日本語訳です。 The Mistakes I Made As a Beginner Programmer 初心者プログラマが犯しがちな間違いと、それらを特定し、避けるための習慣を学ぶ方法。 まず最初に言っておくことがあります。 この記事は、誤りを犯すことを悪いと糾弾するために作成されたものではありません。 むしろ貴方が誤りに自ら気付き、あるいはその兆候を見いだし、それらを避けられるようにするために書かれたものです。 私は過去これらの誤りを犯し
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Javaプログラムを書く上で守るべき一般的な指針をまとめておきます。 Java言語の命名指針(ルール) おおまかに以下のルールで命名することができます。 すべてのUnicode文字が利用できる 日本語(マルチバイト文字列)なども利用できるが慣例的に以下のみで構成することが多い 英数字 アンダースコア( _ ) 先頭文字に数字は使えない 文字数制限はない 大文字と小文字は区別される 予約語は使えない (参考)予約語一覧:Javaの予約語 1. クラス名 Pascal記法 先頭を大文字 それ以外は小文字 言葉の区切りは大文字 例 ・Perm
とりあえず動けばいい、の精神でコードを書ける個人開発とは違い、仕事やオープンソースプロジェクトにおけるコーディングでは、「他人が読むコード」を意識して書く必要があります。 他人が読むのですから、もちろんわかりやすいコードでなくてはなりません。でも、「わかりやすい」とは何でしょう。どうしたら実現できるのでしょう。 この記事では、他人が読む可能性があるコードを書くときに気をつけていた方がいい事項について、いくつか紹介します。 まえがき 私が社会人になって数ヶ月が経ちました。会社では自分でコードを書くのはもちろん、他人の書いたコードをいじるという、今まであまり経験していない作業をすることもあります。 そしてその中で使われている言語にはJavaScriptも含まれます。JavaScriptは平易な言語であり、クライアントサイドでもサーバサイドでも採用できるので、様々な場面で使用されています。 さす
この記事は、PowerShell Advent Calendar 2017 3日目の記事です。 https://qiita.com/advent-calendar/2017/powershell 新しい言語を触るとき、その言語はどのように書くことを意図しているのか気になります。私が触ってきた言語の多くは「その言語の考えの基本」となるものを持っており、コーディングガイドライン上でもそれを明示していることが多いようです PowerShellはどうなのでしょうか? 今回はPowerShellではどのようなコーディングスタイルで書くといいのかを考えてみます。 ※ 本記事ではコーディング規則も同じ意味で用います 思いのほか記事内容がながくなってしまったので、結論だけ見たい方はまとめをどうぞ ※ 決してこの記事の内容が絶対正しいと思っていません。みなさんが書いていく中でどうすればいいのか、と思ったとき
このサイトは Google JavaScript Style Guide(Revision 2.93) を私的に日本語訳したものです。 この翻訳の内容について、翻訳者は一切の責任を負いません。ご利用は自己責任でお願いします。 以下のコーディングルールは、最終的にコードをClosure Compilerにかけて完成させることが暗黙の前提となっている点に注意してください。Closure CompilerはGoogle自身が提供しているJavaScript圧縮・最適化ツールです。(こちらの日本語の解説も参考にしてみてください。) JavaScriptコードがこのスタイルガイドに適合しているかどうかを検証する、Clisure LinterというツールがGoogleから提供されています。使い方はこちらを参照してください。
はじめに 本文書はSQLのスタイルガイドです。 PythonやRubyのようなプログラミング言語には有名なスタイルガイドがあり、共通のレイアウトルールに沿ったインデントや命名規則に則ったコードが生み出されています。 一方、SQLには知名度のある統一されたスタイルガイドがありません。 そのため、思いのままに書かれたSQLが散見されます。 もちろん、SQLを使ってアドホックな分析を行う場合は、必ずしもルールに沿う必要はなく、効率よく書いても良いと思います。 しかし、Webサービスやバッチの中に組み込むようなもの、つまり自分以外の誰かに読まれるSQLは、多くのプログラミング言語同様に何らかのスタイルガイドに沿うことで多くのメリットを享受できると思います。 クエリが構造化され、可読性が高まる バグの発見や修正が容易になる 改行位置やインデントなどのフォーマットの悩みが解消される スタイルガイドを共
会社やクライアント側で特にコーディングガイドラインが決めれてなかったり、フリーランスだけど結構好き勝手にコーディングしている、なんて時に1つの指針にできるようなコーディングのガイドラインを作ってみました。 また、Compass+SCSS記法を使用する場合はBEM(MindBEMding)を使った方が良いとは思うけど、複数人などのチームで初めて導入する時は少し敷居が高い気がするので、命名規則に関してはOOCSS、略語はMCSSの思想に基づくこととします。 前提 上記で書いたように本来はBEMるのがベストだけどあくまでBEMらない時に使うガイドラインです。 記述に関して結構当たり前としているところはすっ飛ばします。(CSSでプロパティとバリューの間は空ける、とか) 思想だけじゃ足りないルールはプロジェクトファイルにREADEME.mdなどにルールを記載しておくと良いと思います。 言わずもがな既
ThinkfulはWeb/スマートフォンアプリの技術などを学ぶことができるオンラインスクール。プロフェッショナルな開発者がメンターとして1対1で伴走するため、他の同様サービスよりも続けることができる。 Javascript ベストプラクティス パート1 2つのパートに分けてお届けする「ベストプラクティス」のパート1では、MozillaのWebエバンジェリストであるChristian Heilmannが提供する人気のスライドショーから内容を抜粋しています。JavaScriptにはひどく扱いにくい特徴がいくつかありますが、それはこれまで以上にソフトウェア開発において重要になっています。この「ベストプラクティス」ではより読みやすく、効率の良いコードを書く手助けとなるサンプルコードやその使用例を紹介していきます。 もしWeb開発についてもっと学びたいと思うのであれば、私たちが提供しているフロントエ
JavaScriptは移り変わりの早い言語です。 もう1年以上経っていますし、記事のメンテもちゃんとできていないので、消し線を入れることにしました。 参考程度のために記事は一応残しますが、より新しい情報を読まれることをお勧めいたします。 はじめに --- 最近では JavaScript の実行環境はブラウザに限りません。(node.js, Web Workers) また、旧来のような <script> 経由でのロードもとうに古くなっています。今は CommonJS スタイルで、require を用いたモジュールのロードを行なうことがより良いとされています。 ですから、次のようなことは改める必要があります。 ~~- var YourModule = {}; などとして、外部から YourModule.hoge(); などと呼び出す書き方 this === window だと思うこと~~ 今回
2023年1月1日 2022年の振り返り 今年は良くも悪くも某国際球技イベントに振り回された年だった。 2022年11月23日 eslint-plugin-importによってVitestの設定ファイル上でエラーが発生する場合がある vitest と eslint-plugin-import に依存している環境では、vitest.config.ts内で vitest/config をインポートすると Unable to resolve path to module 'vitest/config'. eslint(import/no-unresolved) というエラーが出る場合があります。 2022年8月24日 Next.js + Vercel + microCMSなどを使ってほぼ無料でブログを運用する 当ブログのシステム構成について紹介します。構成を真似することでほぼ無料(後述)でブログ
フロントエンドの世界では、日々新しいフレームワークやライブラリが生まれています。 初めてそういった新しいものを習得する場合に、なるべくなら近道したいと思うのが人の気持ちだと思います。 まず大変なのが、Hello World から実際のプロダクトやプロトタイプで利用する場合で、これは初めてで何もわからない土地を一人で散策するような感覚にも似ています。 今日、紹介するのは私が進化の早いフロントエンドの世界で、より早く未開の土地に慣れるためにスタイルガイドを有効活用しているという話です。 ちなみにこの記事はFrontrend Advent Calendar 2014 - Qiitaの 6 日目の記事です。 5 日目はじめての CSS 設計 - Qiita(@moschann) 7 日目CSS のプリプロセスとポストプロセス、そして Rework と PostCSS(@morishitter) 良
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? HTML と CSS のコーディングルールを作ろう HTML と CSS のコーディング規約を中心に、メンテナンス性の良い HTML や CSS をコーディングする際に重要だと思うポイントをまとめています。 誰に向けた記事か この記事には、HTML や CSS を書く人に役立ちそうな内容が書いてあります。 特に初級者から中級者の方で、HTML や CSS を一通り学習した方からの反応が良いです。 まだ HTML や CSS の学習を始めて間もないという方は、先に案件やプロジェクトをこなしコーディング経験を積むことをお勧めします。経験を積
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 デメテルの法則 別名最小知識の法則。デメテルは、豊穣の女神。アスペクト指向などの研究であった「デメテルプロジェクト」に由来。 基本的な考え方は、任意のオブジェクトが自分以外(サブコンポーネント含む)の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。 単純化して説明すると、オブジェクトの"メンバーのプロパテ
実務でよく使う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. ア
はじめに 他の人が書いたコードを読んでいるときに時々気になるのが、英語の間違いです。 特に動詞、名詞、形容詞の使い分けが間違っていたりすると、かなり違和感を感じます。 そこで今回はモデル(=クラス)やメソッドに名前を付けるときの基本的な原則をまとめてみます。 また、英文法的に正しい品詞が選べるようになるための習慣についても最後に説明します。 想定する言語/フレームワーク この記事の説明ではRuby/Ruby on Railsを想定しています。 ただし、基本的な考え方は他の言語でも同じように使えるはずです。 モデルの名前は名詞にする 例: 「支払い情報」を表すモデルを作りたい場合 × Pay ○ Payment 「支払う = payか。よし。」でモデルを作ってはいけません! payは動詞で、payの名詞形がpaymentです。 Payモデルではなく、Paymentモデルを作りましょう。 例:
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く