英語の文章に触れる機会が増えると目につくのが英語の括弧。「英語で括弧はなんと呼ぶんだろう？」「使い方は日本の括弧と違うのかな？」など、気になっている人も多いのではないでしょうか。実は、日本語で何気なく使っている括弧が英語では使われないなど、両者には違いが見られます。 こちらの記事では、英語での括弧の使い方を徹底解説！よく使われる4つの括弧をはじめ、コロンやセミコロンなどの記号についても紹介します。例文も掲載しているので、括弧がどのように使われるのかしっかりと理解できるでしょう。 English Labは、オンライン英会話「レアジョブ英会話」が運営。英語を「話せる」ようになるには、繰り返しアウトプットする機会が必要です。1レッスン142円のレアジョブ英会話で每日外国人講師と話してみませんか。レアジョブ英会話を見る 英語の括弧は大きく分けて4種類！ 日本語と同様に、英語でも様々な括弧が使われま
2020年に「コミットログは良くならない」というのを悟ったので、現実的な解決案である「git-notesでメモを残す」について記事を書いておきます。 前回の記事 sinsoku.hatenablog.com git-notes 詳細は git notes --help を読んでください。 概要は以下の通りです。 コミットログとは別にメモを残せる コミットはそのままなのでshaは変わらない shaが変わらないのでCIの再実行が起きない 他人のコミットにメモをつけられる 他人に作業を依頼する必要がない メモもリモートにプッシュできる 過去のコミットにメモを残せる 使い方 メモを書く git notes edit <sha> でメモを書くと、git log のときに一緒に表示される。 $ git notes edit d2cdf0b $ git log -1 d2cdf0b commit d2c
私はウンザリしています。 「○○対応」は曖昧なのでやめてください。「○○が■■になるバグを修正した」の方が直接的です。 こんな指摘を、新人が入ってくるたびにコードレビューやドキュメントレビューで繰り返しています。 しかも、新人はなぜみんな同じような分かりにくい表現をつかってきます。 なんなんでしょう？工学部では、こんな言葉遣いをするよう指導してるんでしょうか？ 「レビューを依頼する前にこれを読んどいて！」と言える記事なり本なりがあれば良かったのですが、良いものが見つけられなかった（ご存知なら教えてください）ので、とりあえずレビューでよく指摘する日本語の文章の問題点や変な表現ポイントを列挙しました。 なお「コメントは必要十分な量を書く」「チケット番号やWikiのURLを書く」といった、良く知られた・日本語に限定されない話題は省略しています。 1. 俗称を使わない・造語しない 製品名・機能名な
大企業の中で新しいことをやろうとしている人が言われてやる気をなくすコメントを集めて対処法とセットで若い人に配布したら日本のイノベーションが活発になるのではないかとふと思った
2019年4月に Google の SQL parser/analyzer の ZetaSQL が公開されました。 現在 BigQuery Standard SQL や Cloud Spanner で実装されている SQL 方言であり、 Cloud Next 2019 で BigQuery UI から Cloud Dataflow で実行されるパイプラインを記述できる機能として発表された Cloud Dataflow SQL にも使われることがツイートからも見て取れます。 ZetaSQL については Google の外の人がまともに言及しているのを見たことがなく、聞いたことがないか様子見という人が多いと思うので分かっていることを書いていきます。 既存の文献から見る素性ZetaSQL は Spanner の SQL 実装について書かれた Spanner: Becoming a SQL Sys
この記事はリクルートライフスタイル Advent Calendar 2015 - Qiita の17日目です。 こんにちは。現在、ホットペッパーグルメのエンジニアをやっている敷地@shikicheeです。 gitで英語のコミットメッセージどう書けばいいの？ と思ったことはありませんか？ 英語で書きたいなーって思っても、いざ書くとなると躊躇しますよね。 ネイティブはどう書いてるのでしょうか。 そこで、github上で実際に使われているコメントを解析し、 よく使われている例をまとめてみました。 解析したデータ github上で1万スター以上を獲得している169リポジトリのコミットメッセージを対象としました。 bootstrap、jquery、react、d3、docker、node、tensorflowなどの有名なプロジェクトばかりなので、良いコメントが期待できます。 解析するコミットメッセー
パラメータを決める 次に関数に渡すパラメータを決めます。 関数の名前で表現されている処理を実現するには、どれだけのパラメータがあればよいか？ と考えてみましょう。 今回の例でいえば「お客さんの年齢」と「日付」があれば、すべてのチケット価格が計算できます。 ということで、age と date の2つのパラメータを渡すことにします。 function calculateTicketPrice (age, date) { } パラメータの名前も、なにを表しているかわかるようにしてくださいね。 くれぐれも「hensu」とか適当な名前をつけたり、同じ変数にぜんぜん違う値を繰り返し代入したりすることのないようにしましょう。 テストを書く 次にユニットテストを書きましょう。 テストは常に更新される仕様書です。 業務ロジックをテストに説明させておけば、関数の仕様をコメントにいちいち書く必要などありません。
【意外と知らないＣ言語（2）】 文をコメント化する方法は3通りあります。 （1）// foge （2）/* foge */ （3）/* foge //*/ 3番目は始点を示す /* を削除するだけで、コメント化が撤回されるのでデバッグ時などに便利です。 ＼^o^／
前回書いた「「正しく書かれたソースコードにコメントは必要ない」なんて幻想だという話（ http://d.hatena.ne.jp/t_tutiya/20170519/1495197904 ）」は土屋のブログ記事にしては珍しくはてブやコメント、twitterで反響を幾つか頂きました。その中の幾つかを紹介します。分かっているとは思うけど、サンプルコードはJavaScriptを意識してますがてきとーです。 案１：マジックナンバーを定数化する MAX_OPAQUE = 1.0f //定数宣言のつもり if (alpha < MAX_OPAQUE){ //処理Ａ } "1.0f"に意図を設定すればコメントが不要なのではないか説。うーん、これはちょっと難しいかな……。"MAX_OPAQUE"が正しい変数名だとは思えませんが、どんな名前にすれば意図が説明できるのかちょっと思いつきません。また、数式が複雑
土屋はプログラマの中でもかなりコメントが多いタイプだと思っています。理想を言えばコード１行ごとにコメントを書きたいくらいです（本当は、識別子を全部日本語で書きたいと思っているのですが、これはまた別の話）。 これは土屋がPDL（Program Design Language https://www.gamedev.net/resources/_/technical/general-progra... ）開発スタイルの薫陶を受けているからなのですが、それとは別に「そもそも日本人には英語ベースのソースコードを高速に読解するのは無理がある」と考えているからです。 また、より本質的な課題があると思っていて、プログラミング業界的には「コードがドキュメントであるべき（≒正しく実装されたコードであれば、コメントは最低限になる）」という風潮がありますが、土屋は、これはプログラマが夢見る幻想に過ぎず、「本質的
WebKit 開発者のメーリングリスト webkit-dev を見ていたら、興味深い話題で盛り上がっていた。WebKit のソースコードや ChangeLog のコメントに関する議論だ。 WebKit に限らず、ハッカーというのはソースコードにコメントを書きたがらない。 コメントが古くなってしまい、実情と合わなくなってしまうから、というのが理由としてはよく聞かれる。すぐ古くなってしまうコメントを書くより、元々コメントを書かなくて済むような綺麗なコードを書けよ、とハッカー達はよく言う。 個人的には、コードでは処理の内容は記述できるけれど、意図を記述できないので、意図を補足するコメントぐらいは必要なんじゃないか、と思っているけれども、それすらダメと言う人も時々見かける。 ともかく、今回の議論は自分にとっては興味深かった。 そこでその内容を紹介してみようと思う。 議論はいくつかのトピックに分かれ
ゴールデンウィークなので折角だから借りてきた。 プログラム書法 第2版 作者: Brian W.Kernighan,P.J.Plauger,木村泉出版社/メーカー: 共立出版発売日: 1982/06/20メディア: 単行本購入: 1人 クリック: 166回この商品を含むブログ (31件) を見る──というのは嘘。実際の所は、図書館のカードを更新しに行ったついでに気の迷いで借りてしまっただけ。 以前も借りたことがあるのだが、『プログラム書法 第2版』は良い本ではあるけどちょっと古すぎる。サンプルコードがFortran*1やPL/I*2である時点でこの本の良さが大幅に削がれている。21世紀のプログラマには色々と厳しい。 まあ今や後継たる『プログラミング作法』がある訳で、普通はそちらを推奨するのだが。 ただ何というか、コメントの書き方に関する記述は『プログラム書法』の方が分かりやすいと思うのだ。
人工知能や自然言語処理を活用したサービスを提供するクーロンは7月7日、機械学習や自然言語処理、行動分析にもとづく独自の人工知能を搭載した、読者が健全な議論を交わすための“荒れない”コメントシステム「QuACS（クアックス）」をウェブメディア向けに提供開始した。人工知能を活用したコメントシステムは世界で初めてだという。 ウェブサイトに数行のJavaScriptコードを埋め込むことで、読者が記事の内容に対して意見や感想を匿名でコメントできるようになる。コメントに含まれる言葉や文章の意味を人工知能が解析し、誹謗（ひぼう）中傷や罵詈（ばり）雑言、差別用語、違法取り引き、人権侵害、出会い目的、公序良俗に反する内容である場合に、自動でフィルタリングして表示しないようにする。 「単語」ではなく、同一コメント内の前文の内容、他者のコメントへのレス（会話）の流れなど、文章や文脈を判定しているのが特徴。たとえ
【翻訳】Gitのコミットメッセージに関する注意点
Tim Popeさんの "A Note About Git Commit Messages" を翻訳しました。 元記事はこちら： http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html （翻訳の公開は本人より許諾済みです） 翻訳の間違い等があればブログコメントやTwitter(@oshow)などで遠慮無くご指摘ください。 Gitのコミットメッセージ に関する注意点 良い形式のコミットメッセージを書くということについて、時間を取って説こうと思う。私が考えるに、コミットメッセージ形式に関するベストプラクティスは、Git を素晴らしくしてくれる小さなディティールの一つだ。rails.git への最初のコミットのいくつかは、（折り返しのない）長文による多様なコミットメッセージを含んでおり、なぜこれがはっきり言ってお粗
われわれは、いかにして変更点を追うか ChangeLog/Issueを追う技術 自己紹介 azu @azu_re Web scratch, JSer.info アジェンダ 変更点を ChangeLogで知る Issue/Pull Requestで知る Commitで知る アジェンダ 変更点を Commitに書く Issue/Pull Requestを扱う ChangeLogにまとめる 変更点を追う :mouse: ChangeLogの追い方 ChangeLogを追うにはまずChangeLogの更新に気づく事が必要 GitHubでライブラリのリリースを見ていくためのツールや方法に書いた 更新検知の仕組みや補助ツールについて リポジトリのWatch => azu/github-reader タイムライン => azu/github-reader Star => starseeker GitHu
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
