「サーバー」と「サーバ」、どっちが正解? - 【ビジネス用語】
先日、上司に報告書を提出したら、「この"サーバー"って表現、全部"サーバ"に直して」と言われた。えっ、サーバーじゃないの? ということで、今回のテーマは「長音(―)」。サーバとサーバー、どちらが正しい表現なのか。長音の使い方とあわせてご紹介します。 ■長音とは 「サーバ/サーバー」のほかにも、「コンピュータ/コンピューター」「ブラウザ/ブラウザー」など、「―」を付けても付けなくてもいいような言葉はたくさんあります。話したり耳にする分には気にならないかもしれませんが、文字にしたり見たりした時に「あれ?」と思う人も多いのではないでしょうか。 このように、外来語の長く伸ばして発音する部分を「長音」と呼び、それをカタカナで表記する場合には、長音符号と呼ばれる「―」で表すのが一般的です。主に、外来語の末尾が「-er、-or、-ar」の際に使用しますが、語尾にこの長音符号を付けるか否かについては、それ
MSが長音付けルール変更、「ドライバ」を「ドライバー」に － ＠IT
2008/07/25 「コンピュータ」「エクスプローラ」「プリンタ」は、今後は「コンピューター」「エクスプローラー」「プリンター」に――。外来語のカタカナ表記で“表記揺れ”が問題となる末尾の長音記号（音引き記号とも呼ぶ「ー」）の取り扱いについて、マイクロソフトがルールを変更する。 同社では従来から「2音の用語は長音符号を付け、3音以上の用語の場合は省くことを原則とする」としたJIS規格（JISZ 8301）に準じてきた。私企業として「何らかの外部のガイドラインに従う必要があった」（マイクロソフト 最高技術責任者 加治佐俊一氏）と、これまでJIS規格を参照してきた。ただ、この規格はJISの規格書作成時のガイドラインとして定められたもので、科学技術・工学系のドキュメントなど一部で用いられてきたルールに過ぎない。 新聞や雑誌などでは「長音あり」としたルールを採用するケースが多い。これは1991年
実践テクニカルライティングセミナー－マニュアル作成の進め方とわかりやすいマニュアルのポイント－
<BODY BGCOLOR="#ffffff" LINK="#ffffff" VLINK="#ffffff"> <P> <IMG SRC="../gif/sec3c.gif" ALT="" ALIGN=BOTTOM HSPACE=10 width="540" height="26"><BR> <IMG SRC="../gif/tw2-4s.gif" ALT="" ALIGN=BOTTOM width="570" height="150"><HR><H1> <span style="font-weight: 400"><font color="#800000">技術文書</font>での<font color="#800000">長音記号</font>の扱い方</span></H1> <blockquote> <blockquote> <table border="0" cellspacin
タイミーのRailsアプリをシニアなエンジニアが採点したらだいぶ辛口だった - Timee Product Team Blog
この記事はTimee Advent Calendar 2023シリーズ 1の1日目の記事です。 はじめに こんにちは、タイミーでバックエンドエンジニアをしている須貝（@sugaishun）です。昨年は弊社でアドベントカレンダーに取り組んだか覚えていないのですが、今年はなぜかいきなり3トラックで臨むということで、非常に勢いがあるなと思いました。量と勢いで攻めていくところが弊社らしいなと感じています。全て完走できると良いですね。 さて私はその中のひとつのトップバッターということで、タイミーのRailsアプリケーションについて弊社のシニアなエンジニアたちと雑談した内容を座談会風にお伝えできればと思います。事の発端は弊社Slackのバックエンドエンジニアが集まるチャンネルで「タイミーのRailsアプリケーションの健康度はどのくらいなのか？」という会話をしたことでした。その時の私の感想は「人によって
なぜソーシャルログインの際にemailをキーにして参照するのか
ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2023 の 初日の記事です。 こちら、参加者を募集中です！気軽に参加してみてください！してくれよ！はよ！ なんの話か ちょっと想定以上に反応をいただいたこちらの記事について、ちょっとだけ補足をしたいと思います。 なんの話か詳しく 自分のはてブのコメントをつけたポストにもたくさん反応いただきました。 実際、海外のサービスはメアドをキーにして参照してるところも多く これはサービスのDBのUserテーブルがemailをプライマリキーにしているという話ではありません(が、そう思われた方からDMが来ました)。 最初にパスワード認証やメールでリンクを送信して認証させる仕組みを実装している状態から、ソーシャルログインを実装しようとする際に "email" をキーにした参照をすることがあるんよ
韓国で発生している「手の形」が男性嫌悪（男性器が小さい）を示しているという騒動の歴史的背景 - 電脳塵芥
韓国のゲーム業界がかなり揺れています。発端はメープルストーリーのPV中の1フレームでキャラクターが示している「手の形」が男性嫌悪、要は「チンチンが小さい事を示している」のではないかと男性ネットユーザーの指摘が相次いでいるからです。その該当画像はこちら。 何言ってるんだ？ って感じですが、この左手の形が「チンチンは小さい＝男性を馬鹿にしている」、そしてそこにこれを描いたのはフェミニストだというのも加わっており大炎上という流れ。やはり何を言ってるんだって感じではありますが、アニメーション会社は謝罪や修正をすでに表明している状態です。 https://twitter.com/studioppuri/status/1728673116979896589 さらにメープルストーリーを展開するネクソンは26日0時に問題のPVを非公開化、その日のうちに緊急ライブ放送を行い、ディレクターによる謝罪やこの「手
squash and mergeしか使ってないけど全く困ってない
こういうことはレポジトリ構成・ワークフローと密接に紐づいているので、そういう前提を抜きにはどれがいいとかはいうことはできない。が、自分はいわゆるsquash and mergeのみの環境しかほとんど経験がないし、それで困ったことが一度もない、という話をしておきたいので書いておきたい、ので書いておく。 squash and mergeのメリットは書いてある通りで、基本的にPR内の細かい修正というのはゴミみたいなコミットが多く、メッセージも雑なことが多いので、それをコミットログに残しておくのは嫌だということがある。それよりは意味のある単位のコミットを残しておきたいし、それの単位はPRで行うのが良い、ということだ。 “Google-style” workflow デメリットの方は、いわゆるfeature branchというワークフローで顕在化する問題であると思う。で解決策はあり、それはワークフロ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
