Ruby のメソッド定義時に仮引数があるとき、それをカッコでくくらないのは私だけなの？ - STORES Product Blog
テクノロジー部門で Ruby インタプリタの開発をしている笹田です。RubyKaigi 2024 楽しみですね。 さて、Ruby のメソッドを定義するとき、仮引数がある場合、カッコを省略することができます。 def foo(x, y) end def bar x, y end bar の定義の方法ですね。私は好んでこの書き方をしてたんですが、同僚の遠藤さんに「そんな書き方をしているのは今時笹田だけだ」と言われてショックを受けたので、ちょっと調べてみました。 ちなみに、カッコがないと使えないメソッド定義の方法があるので、その時には涙を呑んでカッコをつけます。 def foo(kw:) # 必須キーワード引数 end def bar(&) # 無名ブロック引数 end 補足１：Ruby では「メソッド呼び出し時にカッコをつけるかどうか」にいろいろな論争がありますが、ここでは「メソッドを定義する
JavaScript Standard Style
JavaScript Standard Style Sponsored by English • Español (Latinoamérica) • Français • Bahasa Indonesia • Italiano (Italian) • 日本語 (Japanese) • 한국어 (Korean) • Português (Brasil) • 简体中文 (Simplified Chinese) • 繁體中文 (Taiwanese Mandarin) JavaScript style guide, linter, and formatter This module saves you (and others!) time in three ways: No configuration. The easiest way to enforce code quality in your
Makefile覚書: Goアプリ開発に役立ちそうな基礎知識 | フューチャー技術ブログ
はじめにTIG真野です。育休明けです。 フューチャー社内のタスクランナーはmakeやTaskなど複数の流派があり、チームによって使い分けられています。個人的にはmakeで良いんじゃないかと思っていますが、Taskも良いですよね。 makeは細かい記法をいつも忘れる＋調べるとC言語向けの情報が出てきて脳内変換に手間を感じたため、makeを用いてWebバックエンドアプリをGoで開発するということをテーマに、役立ちそうな情報をまとめます。 なお、今記事におけるmakeは、GNU Makeを指します。バージョンは以下で動かしています。 MakefileのためのEditorConfigMakefileのインデントはハードタブである必要があります。誤りを防ぐためにもEditorConfigを設定しておくと良いでしょう。 makeは通常、Makefileという名称をデフォルトで認識しますが、同一フォルダ
protolintの自作pluginによるprotoファイルのレビュー負荷軽減のための取り組み - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。cybozu.com Cloud Platformチームの pddg です。Cloud Platformチームでは現在、精力的に cybozu.com のインフラ基盤の移行に取り組んでいます*1。その取り組みの一環として、gRPCを用いたスキーマファーストな開発を推進しています。 今回はスキーマを記述したprotoファイルのレビューにおいて一部のレビュー項目をCIで自動的に確認されるようにし、レビュワーの負荷を軽減できたのでその方法についてご紹介します。 ※ これは Cybozu Advent Calendar 2022 15日目の記事です。 背景 cybozu.com のバックエンドでは、これまではサービスのAPIのスキーマをドキュメント等によりカバーしてきました。これはその実装チームが整備し、適宜更新していくものを指します。しかし、こういったドキュメントはしばしばメンテされ
TypeScript再入門 ― 「がんばらないTypeScript」で、JavaScriptを“柔らかい”静的型付き言語に｜ハイクラス転職・求人情報サイト AMBI（アンビ）
TypeScript再入門 ― 「がんばらないTypeScript」で、JavaScriptを“柔らかい”静的型付き言語に JavaScriptプロジェクトでTypeScriptを導入する際には、“柔らかい”静的型付き言語とするのがおすすめです。藤吾郎（gfx）さんがまとめた「がんばらないTypeScript」のガイドラインです。 TypeScriptは、すべてのJavaScriptプロジェクトで採用する価値のある技術です。TypeScriptとこれに対応したエディタを導入することで、補完や型ベースの整合性のチェックにより、すべてのプロジェクトで生産性が上がります。またリファクタリングも容易になるので、長期あるいは大規模なプロジェクトでも品質を保ちやすくなります。 この記事では、TypeScriptについて最低限の知識とともに、サクッと（どちらかというと既存のプロジェクトに）導入するための
Rustで普通にプログラミングするだけでMISRA-Cのルールを90%満足できる - 低レイヤ強くなりたい組込み屋さんのブログ
はじめに 2019/2/10追記 記事を書いてから気づいたのですが、正確には、Rustのアトリビュートをいくつか設定すれば、MISRA-Cのルールを90%満足できるでした。 私はMISRA-Cのコーディング規約でプログラミングしたことがないため、内容に誤りがありかもしれません。間違っている点があれば、ご指摘いただけるとありがたいです。 後、いつも通りですが、C言語を貶める意図は一切ありません。 昨日からtwitterで、Rustが組込みのセキュリティが重要な分野で広まると良いなぁ、という議論がありました。 その中で、車載では、やはりMISRA基準との関係が明確になること、ということが1つの基準になりそうでした。 github.com @hashaskell さんから、MISRAコーディングルールのうち、Rustコンパイラがアトリビュートの設定を含めて、保証するルールのリストを作成しているレ
ホーム - CloneTracker
当社はCookieを使用して、お客様が当社のWebサイトでより良い体験を得られるようにしています。引き続き閲覧する場合は、プライバシーポリシーに同意したことになります。
autopep8 version 2.0を目指して | hexacosa.net
autopep8は初版であるバージョン0.1 をリリースしてから7年程経過していて、 2018年09月現在のバージョンは1.4 である。 Pythonのオートフォーマッタ界隈は割と戦国時代で、autopep8の他にも、 非公式だがGoogle傘下のyapf 、 ここ最近急速に人気を博してきている Black なんかがある。 GitHubスター数でいくとyapfもBlackもautopep8を遥かに凌駕している。 yapf 初期コミットは2015年頃。 autopep8にも一時期コミットしていただいてたメンバーがいて面白い。確かグーグラーのはず。すげぇ。 autopep8の動作に嫌気が差したのかもしれない。 どちらかというとPEP8にフォーマットするというより、定義したスタイルにフォーマットするという用途の模様。 yapfのREADMEを見るとgofmtっぽいとも書いている。 Black 初
モダンなJava開発ガイド (2018年版)
2018年現在でもJava開発をしていると、Antすら使っていないEclipseプロジェクトにそこそこの頻度で出くわします。Eclipseの自動コンパイルが通ればOKであり、ビルドはExcel手順書をもとに手動で行われ、依存関係ライブラリはもちろんlibフォルダに各種jarファイルが放り込んであります。Eclipse上以外ではどう動かせば分かる人がいないため、コマンドラインからビルドなどを行うことは叶わず、CI化なんて夢のまた夢です。 そんなJava開発から脱却したい人向けのJava開発のモダン化ガイドです。 基本的にJava 8以降での開発を想定しています。 OpenJDK/OracleJDK上での開発を想定しています。 Android開発の場合は一部適用できない可能性あり。 英語のIDE、ツール等は積極的に使用します。 英語嫌いだとモダン化は難しい。 Java開発全般を前提としているた
そろそろコードレビューそのものの必要性について考えるときがきているのかもしれない - タオルケット体操
技術ブログの方に書くか迷ったのですが、かなりポエムの類な文章になりそうなのでこちらに書きます。 ちょっと前にバズったこちらの記事 medium.com に触発されました。 ちなみにコードレビューに関する話としてはまだ僕が色々と手探りだった3年前にもこんなことを書いていたようです。3年前の自分の考えに触れられるブログって面白いなという気持ちとこいつどんだけ軽率な文章書いてんだよという気持ちが合わさり甘酸っぱい気持ちが生み出されました。 hachibeechan.hateblo.jp 当時と今では日本全体の技術的トレンドも変わっていますし、そもそも僕の所属している会社も違います。今の会社ではGitHubを使っており、コードレビューが当然のフローとして組み込まれています。 そしていま改めて当時のブログを読み返したのですが、びっくりするほどコードレビューに対する僕の考えが変わっていないので、改めて
Swiftでas!と書く場合のガイドライン - soutaroブログ
as!って言うのは、要するにダウンキャストできない場合にプログラムを終了させるものである。 if let x = expr as? SomeClass { f(x) } else { fatalError() } と書くのであれば、 f(expr as! SomeClass) と、同じことなので、as!で書いた方が良い。その方がタイプ数が減るし、コードの見た目も簡潔になって理解しやすくなる。長いコードはそれだけで苦痛だし、なにか間違ったプログラミングをしていることを示すシグナルにもなる。ダウンキャスト失敗の場合に終了するためだけにifを書くことは、全体的なコードの乱雑さを増してしまい、本当の問題の見落としに繋がる。 ただし、as?とかas!とかダウンキャストをしてる時点で、そのプログラムには潜在的な問題があると考えることもできて、本当にダウンキャストが必要なのか3回くらい考えた方が良い。
JavaScript(ES2015)でvarやletを使う必要はほぼ無い - id:anatooのブログ
ES2015でvarやletを使う場面はほとんど無いので、まずconstを使う。constだとダメな場合にはletを使う。 背景 ES2015では、変数を宣言するための文法としてconstとletが導入された。 const foo = 'foo'; let bar = 'bar'; constは再代入できない変数を宣言できる。letは再代入できる変数を宣言できる。 const foo = 'foo'; foo = 'hoge'; // ERROR let bar = 'bar'; bar = 'hoge'; // OK あれ、じゃあvarとletは同じなの？っていうとそうではなく、letやconstはvarとは違って、関数スコープよりも細かなブロック単位のスコープを提供する。例えばconstやletを使うと、if文やfor文などのブロック中でのみ有効な変数を宣言できる。 で、プロジェクトに
10年のツケを支払ったフロント界隈におけるJavaScript開発環境（2016年4月現在）。 - 日々、とんは語る。
2015年はCSSが普及した以来となる10年に1度のフロントエンド大変革期で、それまでのツケが一気に回ってきたと個人的に感じていました。目まぐるしく状況が変化していきましたが、2016年になり、個人的にだいぶ落ち着いてきたと感じているので、ここらへんでまとめておきたい思います。 最初に結論を書いておくと、 『React + Redux + react-router + material-ui + axios + ES2015 + Babel + webpack + ESLint + Airbnb JavaScript Style Guide』 という組み合わせが、いま僕の採用しているJavaScriptの環境です。 主要ライブラリは React A JavaScript library for building user interfaces | React 去年、一気に普及したReact
ホーム - CloneTracker
当社はCookieを使用して、お客様が当社のWebサイトでより良い体験を得られるようにしています。引き続き閲覧する場合は、プライバシーポリシーに同意したことになります。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - psf/black: The uncompromising Python code formatter
Nondestructive_TypeScript.md
CodeReviewComments
GitHub - hadolint/hadolint: Dockerfile linter, validate inline bash, written in Haskell
AndroidLint #DroidKaigi
GitHub - rubocop/ruby-style-guide: A community-driven Ruby coding style guide
