タグ

2018年10月6日のブックマーク (6件)

  • エンジニアのための、いますぐ使える文章校正テクニック - ICS MEDIA

    ウェブ制作や開発の仕事で文章を扱う機会は多いはず。書き手は不自然に思っていない文章でも、読み手は違和感をもっていることがあります。文章校正テクニックを覚えるだけでおかしな表現は少なくなり、読みやすい文章を書けるようになります。 記事では、ICS MEDIAで実践している文章校正の一例を紹介します。 レベル1、基的な校正ルールを使う いろんな場面で使える基的な文章校正テクニックから紹介します。 テクノロジー系の名詞は正しく記載しているか テクノロジー系の名詞を間違って使うと、「当に技術に詳しいの?」と読者からの信頼度が下がります。名詞は大文字小文字、スペース有無含めて正確に記述しましょう。 GithubGitHub(Hは大文字) JavascriptJavaScript(Sは大文字) After Effect → After Effects(複数形の「s」を忘れてはいけな

    エンジニアのための、いますぐ使える文章校正テクニック - ICS MEDIA
  • 文章作成・メール作成に役立つ! VS Codeの拡張機能「テキスト校正くん」を公開 - ICS MEDIA

    文章の校正チェックを自動で行うVisual Studio Codeの拡張機能「テキスト校正くん」を弊社からリリースしました。無料で利用できます。 テキスト校正くん – Visual Studio Marketplace 短い文章であれば目視でもチェックできますが、長文になるとチェックに時間がかかり見落としも多くなってしまいます。また、いくら内容のいい文章を書いても誤字や脱字が多く体裁が整っていないと、印象が悪く読みづらい文章になってしまいます。 そんなとき、「テキスト校正くん」を利用することで、文章チェックの手間を軽減でき、文章の品質を高めることができます。 ▲VS Codeの拡張機能「テキスト校正くん」 「テキスト校正くん」でできること この拡張機能は、VS CodeでテキストファイルやMarkdownファイル等の日語の文章をチェックします。編集時に自動で校正のチェックを行い、エディタ

    文章作成・メール作成に役立つ! VS Codeの拡張機能「テキスト校正くん」を公開 - ICS MEDIA
  • 「本日増員20名が来る。マシンはまだない」信じられないPMの言動10選 - paiza開発日誌

    Photo by thejbird こんにちは。倉内です。 先日PM経験を振り返って反省する記事を書いたばかりですが(さまざまな反応ありがとうございました!)今度は前職でプロジェクトメンバーだった頃に遭遇した、いろいろなプロジェクトでの「信じられないPMの言動」をまとめてみました。 このようなPMを反面教師にしきれなかった部分ももちろんありますが、「自分はこうならないぞ」と戒めにしていた部分もありました。 今回は私の経験談だけでなく、SEの友人にヒアリングした内容も含めています。もちろん表に出せるものだけを厳選しているのでご安心ください! 信じられないPMの言動10選 1.「年末年始休む人は理由含めて報告して」 出る前提かい!というツッコミはもはや入れる元気もありませんでしたが、デスマってると休むのが異端みたいな空気ありますよね。怖い。 みんな頑張って出るならまだ納得できるのですが、実作業

    「本日増員20名が来る。マシンはまだない」信じられないPMの言動10選 - paiza開発日誌
  • 社内管理画面を Vue + Go で作る - Gunosy Tech Blog

    広告技術部のUTと呼ばれている @mocyuto です。 普段は広告配信のバックエンドを主に担当しています。 今回は社内管理画面を作った話をお伝えしたいと思います。 はじめに 設計 バックエンド goa 構成 フロントエンド 構成 TypeScript Vuex Atomic Design まとめ はじめに Gunosyの管理画面ではRailsが多いですが、社内用管理画面を新規で作ることになり、Vue + Go のSPA(Single Page Application)で作ることにしました。 管理画面をVueGoで作る事例は最近増えてきていますが、弊社でもすでにこの組み合わせで実績はあり、2つ目となりました。 今回の社内向けの管理画面の作成意図としては、ABテスト反映の高速化が目的です。 今までは、リリースフローは以下のようになっていました。 配信チームとロジックチームをまたいでファイル

    社内管理画面を Vue + Go で作る - Gunosy Tech Blog
  • 電子書籍ストアアプリに本棚機能はどこまで必要か? : Tedious Days More×3

    なことに気づくと思うのです。 そして、一度それに気づくと徐々に棚機能の存在価値が低下していくことになり、電子書籍においても棚の整理が面倒になりかねません。使わない棚をいちいち整理するのも面倒になってきます。 それと同時に思うのです。 購入書籍の整理という点ではクソカス最低な Kindle ストアアプリだけど、購入書籍数が2千冊を超えている状態では棚機能なんか別になくても検索が迅速にできれば実用上は問題ないのでは? 同じく購入書籍数が2千冊を超えていながら棚機能が一つの売りである BOOK☆WALKER アプリで、ちまちまと棚で購入書籍を今なお整理している時に、いつもそう思うのです(^_^;) 紙書籍を棚に綺麗に整理していた人なら、電子書籍でも同じようなことをしたいと思うでしょうし、そのために棚機能は必須の機能です。 自分なりの分類・順番で自分の蔵書を棚に綺麗に並べる、とい

    電子書籍ストアアプリに本棚機能はどこまで必要か? : Tedious Days More×3
  • 20 万行超のコードベースをテストせずにリファクタリングリリースした話 - MonotaRO Tech Blog

    こんにちは、鈴木です。 20 万行を超えるアプリケーションのほとんど全てのソースコードを変更し、テストを行わずに番リリースしました。 「それってテストいるんですか?」問題 いきなりですが質問です。ソースコードを 1 バイトでも変更したら再テストする必要はあるでしょうか。「絶対に再テストすべき」という方もいれば、「状況によるしケースバイケースかな・・」という方もいらっしゃると思います。 ケースバイケースと考える方は、どのような場合にテストを行わなくて良いと考えるでしょうか。例えば、コメント内の誤字を修正した場合はどうでしょうか。ローカル変数の名前を typo していたので修正した場合、デッドコードを削除した場合はどうでしょうか。 こんなことがありました ある日、Python のソースコードを眺めていると、「# $Id」のような CVS 時代のコメントがありました。いまやソースコードは Gi

    20 万行超のコードベースをテストせずにリファクタリングリリースした話 - MonotaRO Tech Blog