エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

eclipse4.7 新機能まとめ

Eclipse 4.7

f:id:suzaku0914:20170708062419j:plain

毎度のことながら、よくお世話になるIDEなので、キャッチアップのために調査。
最近は、TypeScriptやっているせいか、Visual Studio Codeを起動することが多くなってしまったけどね。。。
今回は、地味めなデザインだな。
いつもは、キラキラした派手な画面の印象があるが。

公式サイト

本家

Eclipse Oxygen

Pleiades

日本語化 Eclipse 4.7 Oxygen オキシゲン | MergeDoc Project

変更内容

全部は無理なので、気になった箇所だけ。
もっと知りたい場合は、参考サイトに貼ったリンク先が内容が濃い。

カバレッジ分析

カバレッジ計測のプラグインであるEclEmmaが標準で装備。
EclEmmaにクセがあり意図しない挙動があるようだが、通ってないコードを見分けやすくなった。
以前に調べたことがあったので、そちらを参照してもらえればと。

suzaku-tec.hatenadiary.jp

Git

いろいろ操作性が改善したらしい。
自分は根っからのSourceTree派なので、あんまり興味が沸かなかった。。。
説明は、下記のリンクを参照。

Eclipse 4.7 Oxygen 新機能 30+ / Java 9 を試そう! - Qiita

修正内容が、かなり多い。
Gitを覚えることの重要性が伺える。

トリガーポイント

ある特定のブレークポイントを通過した場合だけ、トリガーポイントに設定した箇所でとまるようになる機能。
機能の共通化している箇所で、特定のブレークポイントに入ったときにだけ、共通部分のロジックをデバックしたいことはあるはず。
それが、楽にできるようになったってことだろうね。
以前は、共通部分に入る前にブレークポイント貼って、止まったあとに、共通部分にブレークポイント貼ったりして、かなり面倒だった。

二重起動抑止

今までなかったのか。。。
eclipseは重いから、そもそも二重起動しようと思わなかった。
システム的に防止してくれるなら、誤操作で起動は減るかもね。

ウィンドウ > 設定 > 実行/デバッグ > 起動 から、「起動中に終了して再起動する」にチェックを入れる。

エディター切り替えの改善

ワイルドカードの利用が可能になった。
マウス操作しがちだから、あんまり使わないが、覚えると楽なのはたしか。
今は潤沢なメモリもあるし、コマンドによるエディタ切り替えを、覚えて損はないと思う。

参考サイト

qiita.com

大変参考になりました。

【Software Design】2017年7月号 及川卓也のプロダクト開発の道しるべ リーンキャンバス まとめメモ・感想

きっかけ

リーンスタートアップに釣られた。
たぶん、自分がいましている開発もリーンスタートアップに分類されるような気がしたから、まとめメモと感想を書くに至る。

リーンスタートアップ

起業家が一番恐れることは、作ったサービスが顧客に届く前にリソース枯渇すること。
最初に考えたアイディアが当たればいいけど、そんなことは稀。

これを成功に導くために行う考えが、リーンスタートアップ
やることは単純で、仮設→検証→修正を繰り返すだけ。
もしくは、構築→計算→学習とも表現される。

口で言うのは簡単だが、実際にやるとなったら大変。
やることは誰かに求められているものをリソース枯渇する前に作ること。

リーンキャンバス

事業計画相当のものを1枚のキャンバスで表現したもの。

構成要素として下記の内容が存在する。

  • 課題
  • 顧客セグメント
  • 価値の提案
  • ソリューション
  • チャネル
  • 収益の流れ
  • コスト構造
  • 主要指標
  • 優位性

課題と顧客セグメント

顧客にとって重要なのは、製品ではなく課題が解決されるのかどうか。
課題が明確化してないのに、それを解決できる製品は売れなくて当然。

そして、その課題をどのような顧客が持つのか具体化することで、付加価値を高めるのは何なのかを明確化できる。

価値提案

どのように位置付けられるかを示す。
既に存在している別製品のメタ表現が期待されている。

ソリューション

課題を解決する機能。
ラフでOK

チャネル

顧客へ届ける手段。

収益の流れとコスト構造

ビジネス起こすんだから必須の考え。
事業をどうやって成立させるのか考える。

主要指標

製品の有効性を測るために見るべき指標を決めておく。
複数見ることもある。
段階や見るべきタイミングも考慮しておく。

優位性

強豪が簡単に真似出来ないものを考える。

感想

起業家の視点が足りてないからだろうか?
あんまり頭に入ってこなかった感じ。
なんかのシステム開発に望む時は、ココらへんをもうちょい意識してやってみよう。
たいてい、隠されていて、何考えているのか分からんところが多いけどね。。。
何年もシステム開発できるとも限らないし、起業家の考えは早めに身につけたいな。

【雑記】Typescriptと充実感が得られてないと感じた原因の考察

きっかけ

仕事でTypescript使っているけど、なんか仕事しても充実感?達成感が得られないので、考察した結果をメモる

現状

やっていることは、データの橋渡し。
ハードからあがってきた情報を、クラウドへ打ち上げる前くらいのところを担当している。

クラウド上に展開されているアプリに食わせるために、データを加工しているのが主な仕事かな?
あとは、ハードからあがってくる情報を抽象化するってのもある。

考察

おそらく、グルーコードばかり書いているからだろうと思われる。
なんというか、結果がダイレクトに見えるところじゃないからかも知れない。
ハードは、操作が関係してくるから、作ったら操作して動けば、嬉しいと思う。
しかし、俺が作っているのは、ハードの凄いコードが打ち上げてくるデータの加工。。。
どうしても、ハード側のコーディングの方がすごそうに見えてしまうってのが、心の中である。

前まではJavaばかりやってきたので、ネイティブ系のプログラミングには、憧れがあるのかも知れない。
Javaエンジニアなら、共感してくれる人が多いと信じたい!
無性にWebと関係ない箇所のプログラミングをやってみたいって感覚に、とらわれる事がある。

やっていることは、重要なことだと思うけど、それを実感しにくいんだよね。。。
バグが起きたら、障害切り分けのために真っ先にこっちに問い合わせがくるのも、結構シンドイ。。。
最初は、分かんないことが多すぎて、いろんな人に聞いて回ったりするのが、心理的にくるものがある。
おかげで、全然関与してない部分のログを見れるようになってしまった。

これからどうするか

書いて思ったが、意外と俺凄いんじゃね?って思えてきた。
実感しにくいのが、問題だね。。。
振り返ると、意外と凄いことしてたんだなと思う。
システムの全体像を把握しているわけなんだから。
ただ、自画自賛はちょっとキモいって感じるけどね。。。

仕事で充実感を得られなかったら、たまに振り返って、やってきたっことを見直すのはありかもしれない。
成果が見えにくいならなおさら。
たまに、振り返りの機会をもうけようと思う。

【WEB+DB PRESS】Vol.99 良いコードってなんだろう?まとめメモ・感想

目次

  • 良いコードを書く理由
  • 変数、定数、メソッド
  • クラス
  • モジュール
  • チーム開発でのテクニック

感想・まとめメモ

良いコードを書く理由

良いコードとは?

  • 仕様通りの挙動
  • 可読性
  • 将来の変更に強い

仕様通りの挙動

バグが無いことの証明はできない。
証明する場合は、悪魔の証明になる。
仕様通りに動いていることを証明するためのテストと、それに向けてのコーディングは、良いコードを書く上の前提だということ。

可読性

名前を適切につけて、読む人に分かりやすくする。
個人的には、理解するまでの時間が最短になるようにするってのが重要だと思う。

変更に強い

これは、簡単なようで実は難しい。
若手の頃はよくわからなかった。
どうやって変更に強くすればいいのかと、毎回疑問に思っていた。
要するに、絶対的な価値をどこに置くかの問題。
ソフトウェア開発なら、ビジネス仕様が絶対。
ビジネス的に変わらない箇所と、変わる可能性が高い箇所を判断して作る。
ビジネスを理解することが、変更に強いソフトウェアを作ることの第一歩だと思う。

絶対良感を育てよう

雑誌で言っていた意味は、良いコードを見たときに、それが何故良いのか説明できる能力のことだそうな。
個人の主観によるのでは?とも思ったが、それを身につける方法は納得。
身につけるには、OSSを見たり、フレームワークのコードを追うなど。
良いコードについて議論するのは、周囲の人の民度によるかもしれないね。。。
たまにマサカリ好きが居たりもするからね。。。
良いコードの議論となる対象は、議論する人が書いてないコードがいいと思う。

あとは、常にコードを書くこともあった。
やろうと思うんだが、なかなか題材が見つけらないんだよね。。。
家に帰ると、どうしてもアニメみたりゲームしたり、ポケモンGoやって帰りが遅くなちゃったりする。
おそらく、常日頃からコーディングする題材を探すようなマインドがないとダメなんだろうな。
なるべくそうするようにはしているが、実践は難しい。

変数、定数、メソッド

変数

悪い変数は、情報量が少なく、理解を妨げる。
良い変数は、スコープが狭く、変数名で意図が伝わる。

スコープを狭くするは、激しく同意!
たまに、クラス変数・メンバ変数を気軽に使うヤツがいるが、かなり危険。
どれくらい危険かと言うと、いろんな洗剤をバケツに入れるくらい。混ぜるな危険だ!
何でかというと、どこでどう制御しているのか、分からなくなる可能性が高い。
今は大丈夫でも、ソフトウェアが進化したら、複雑化してワケワカメになる。
だから、作る時は、なるべくスコープを狭くしてやることが大事。

定数

定数を使うのは、だいたいマジックナンバーを減らすことが目的な事が多い。
ただし、マジックナンバーを減らすためにマジックナンバーの名称そのままでネーミングするのはダメね!
マジックナンバーの定数を切る時は、そのマジックナンバーの意味を定数名にしないと意味ない。

たとえば、Javaで例をあげると下記みたいなのはダメ。

public static final int TWO = 2

これ、なんの数値なのか全然分からへんがな!ってなる。
たまに、こういう変数名をつける輩がいるので、レビュー時は注意しないといけない。

メソッド

メソッド切り分けする理由

  • 関心ごとの集約
  • 再利用性を高める

つまり、DRY原則に従えってこと。
過度な原則の適用は注意。

メソッド名

  • 簡潔
  • わかりやすい単語
  • やりすぎない

詰め込まず、やりたい関心事に細かく分類して、名称をつけてやれば、基本的に上記は満たせると思う。
メソッド作って満足せず、見返して、詰め込み過ぎてないかチェックする習慣をつけないとダメだね!

テストしやすいメソッド

テストしにくいメソッドは、だいたい関心事の分離ができてないことが多い印象。
作ってテストしにくいと思ったら、そのままテストコード作るんじゃなくて、作ったコードを見直す。

あと、テストしにくいコードは、開発者に負荷がかかりやすいので、必ず見直した方がいい。

名前の付け方

自分は、codicってサイトをよく使う。

codic - プログラマーのためのネーミング辞書

ドンピシャなネーミングをつけてくれるので、結構使う。
ネーミング規約とかある場合でも、参考にはなる。

絶対的な価値観を自分に置かないことだと思う。ネーミングは。
結局のところ、読み手がわかりやすくないといけないから、ネーミングに迷ったら、だいたい自分は近くの人に聞いて、意味が通じるかを試す。

クラス

かなり難しいんだよね、クラス分割って。。。

責務の分割

責務分割は、鬼門。
経験が浅いと、余計な分割をしまくって、クラスのメリットが薄くなる。

システム全体を見て、登場人物達がクラスにあたるハズなので、いきなりクラス設計せずに、全体の概要を掴むことを優先する。
全体像がつかめたら、あとは責務について自問自答。
下記の点について確認する。

  • 責務が集中してないか?
  • 責務がかぶってないか?
  • 責務の境界は明確か?

デザインパターン

GoFが考えた設計のパターンのこと。
ココらへんは、ググるwikipediaの内容を見れば大丈夫だと思う。

デザインパターン (ソフトウェア) - Wikipedia

雑誌で紹介されていたのは、FacadeとStrategyの2つ。

Facade

複雑な手続きを誰かに代行してもらおうというパターン。
個人的な感覚ではあるが、使い方を間違っていることが多い気がする。
なんというか、別のクラスにアクセスするための通り道みたいな感じ。
直接呼べばいいやん!ってことが往々にして感じる事がある。
手順の簡略化が、たぶん主目的だと思う。
手順がないようなクラスのために、Facadeを作るんじゃねぇ!って感じかな?怒りの原因は。
日本語訳で「玄関」みたいな感じになっているから、どこかのアクセスするために通過させる場所みたいになっている気がする。

Strategy

アルゴリズムの付け替えパターン。
Stateパターンもほぼ一緒。取り替えるのが、アルゴリズムか、変数かの違い。
例ではcase文使っていたけど、そうすると値を追加する毎に検索方法変わってないよね?が必要になるから、個人的には反対。
やるならenumでキーとアルゴリズムを持たせて、while文で検索させる。
Rubyでできるかは知らない。。。

コイツは、マジでよく使うから、覚えた方がいい。
だいたいビジネスは、決まった値のときに挙動を帰ることが多い。
それを安全にするためにも、Strategyの習得は必須。
拡張性も高いしね!

モジュール

モジュールの概念に深く関わってないから、あんまり個人の考えはないんだよね。。。

Java9を見ていると、依存関係の解決が主目的かな? 時期的に、今見てもふ~んで終わりそうなので、サラッと見て終わり

チーム開発でのテクニック

チームで開発するから、改修しやすいように作ることが重要。

コードレビュー

  • 他人に説明できるように作る
  • 見通しの良さ
  • 属人化防止

相手の理解を助けるコードを書いていくことに重点を置くことが大事。
あとは、メンバーと対話して、チームの価値が何なのかを決めにいく行為も大事。

システム開発

結論としては、ゴールの共有が重要って感じだったかな?
XPについて触れられていた。
あんまりXPって理解してないんだよね。。。
今度、勉強してみよう。

ソフトウェアアーキテクチャ

アーキテクチャは超重要。
なにも考えないで作ると、小手先でなんとかできない問題にぶつかることは必ずある。
最初から考えろは無理だと思うので、問題の都度、どれがいいアーキテクチャなのか、よく考える必要がある。

アーキテクチャでやることは、大きな単位での役割分担を考えること。

関連書籍

この内容読んでたら、やっぱり脳裏には「リーダブルコード」がよぎるわ。。。
あれ、かなり良書だったと、今でも思う。

suzaku-tec.hatenadiary.jp

今後の自身のタスク

  • XPを学ぶ
  • コーディングを習慣化する
  • コーディング題材を探すクセをつける

【書評】頭のいい説明「すぐてきる」コツ

目次

  1. 「わかりやすい説明」は結論から始まる
  2. 頭がいい人は例外なく「説明が短い!」
  3. できる人は「箇条書き」で説明する
  4. 「いい言葉」が「いい人間関係」を生む
  5. 信頼される人は「本気の伝え方」がうまい

感想

呼んで解釈した内容も記載しているので、本には書いてないことも書いてある。

「わかりやすい説明」は結論から始まる

説明の目的とは、仕事で結果を出すこと
※シーンによって説明の目的は多種多様なので、ここでいう説明は仕事でのこと。

説明の効果

  1. 伝える
  2. 伝わる
  3. 結果が出る

結果が出るまで持っていくのが、説明に必要なこと。

説明の順番

聞き手が聞きやすい順に説明する。
つまり、大きな情報→小さな情報の順に説明する。

大きな情報は、相手が知りたいことを察知してやる必要がある。
相手の欲しい情報を返答してあげるのが、説明の基本。

話の種類を伝える

途中から聞く→理解に時間がかかる。
聞き手が、どんな話をするか知っていると理解度が違う。
どういう話をするかは、伝える努力をする。

聞き手との歩調を合わす

いきなり話をすすめる→聞き手の頭に「なぜ?」が残って時間だけがすぎる。
本題に入る前の下準備は、気をつけてないと台無しになるので、話に入る前には力を入れる。
※本題が台無しにならない程度で!

事実として何が起こったのか聞く

出来事の正確な把握は、客観的な情報が必要。
感情的な情報と区別して聞く。

主役となるのは、客観的な情報。

頭の良い説明の基本

  1. 客観的情報の説明
  2. 解釈の説明

解釈は、人によって内容が変わる。

人間は、感情の動物。正論だけでは動かない。(ホリエモンの説明聞いても、行動を起こすのは少数なのを考えれば、納得してもらえるハズ。あと、正論でないものはもっと動かない。)
説明というのは、正論を述べたものになる。
人を動かすには、説明+お願いで行動を促進させ、結果を出させるのが、いい説明。

説明の効果的流れ

  1. 聞き手に心の準備をさせる
  2. 客観的な出来事を伝える
  3. 自分の解釈を述べる
  4. お願い

明確な結論を持ってから説明する。
結論に至る前に、経験をもとにした手順を紹介する。

頭がいい人は例外なく「説明が短い!」

情報量を増やす→混乱するだけ
説明ベタの考えなので、不要な情報は、極力減らす。

頭のいい説明とは、不必要な情報が少ない。
必要な情報とは、聞き手が聞きたいと思っている情報。
説明する時な、重要との高い情報+補足程度に止めておく。
アレもコレもは、聞き手に不可がかかりすぎる。

サウンド・バイトを意識する。
サウンド・バイトとは、ワンフレーズの短い文章。
キャッチフレーズみたいなもの。記憶に残りやすく、イメージを伝えやすい。

説明する人:内容を理解してもらうため、多くの言葉で丁寧に話す
説明を聞く人:簡潔にまとまった話が聞きたい
説明する人と聞く人には、ギャップが生じやすい。
説明する人は、常に聞く人の立場に立って説明しなければいけない。

ポイントメールの基本

文章構成

  1. リマインド言葉
    何の話か思い出させる
  2. 現在地
    現在の状況説明
  3. 方向性
    今後の予定

過去→現在→未来 でまとめると自然なストーリーになりやすく、伝わりやすい。

聞き手への質問方法

  • オープン・クエッション
    回答を考えてもらう
  • クローズド・クエッション
    限定した選択肢から回答を選んでもらう

質問される側(聞き手)は、クローズド・クエッションの方が楽。
なので、説明する側は、相手のニーズを予測してある程度回答を持っていって説明する必要がある。

できる人は「箇条書き」で説明する

説明とは、目の前にいる人だけが対象ではない。
第三者が、後で見返すこともある。
相手に的確にメモしてもらう説明をすることも重要。

ノウハウ

  1. 自分のメモを相手に使わせる
  2. 自分の言葉を相手にメモさせる

視覚的に見せる方法

  • 数字・固有名詞といった重要ワードは目立たせる。
    ただし、必要最低限で。
  • 説明にはタイトルをつける

「いい言葉」が「いい人間関係」を生む

説明で結果を出す→信頼関係を構築して行動してもらうこと

信頼を得るコツ

  • 相手への気配り
  • 継続的な接点を作り続ける

親身になってくれる人の意見を取り入れるのは、人間の性。
説明する時は、協力的な気持ちを持って望む。
ディスりから入ると、結果まで持っていくのは難しい。

信頼されるための重要な要因

言葉を明確に

発声による問題は、なるべく回避。
日本語は、末尾で意味が決まるので、ハッキリとした物言いで言うことが大切。

アイコンタクト

最初だけでなく、最後にもする。
アイコンタクトできないのは、不信感につながりやすい。

逆説後は控える

厨二心を相手に押し付けてはいけない。
ネガティブになり、行動が起こしづらくなる。→ネガティブ・エフェクト
ネガティブ・エフェクトって言葉の響き、カッコイイ!
カッコイイだけで、利用価値皆無なので、注意

ただし、ポジティブになるための逆説後は、使って良し。

信頼される人は「本気の伝え方」がうまい

人が協力したくなる時

  • 応援
  • 恩返し
  • 利用する

相手に行動を起こさせるために、必要になる。

自分の本気を伝える

本気の度合いを相手に見せることは、オリジナリティに直結する。
努力や一生懸命は、やって当然なので、+αの要素を追加しないとダメ。

本気の方向が間違っていると、大抵バカにされるので、注意。
厨二や、意識高い系は、コレに当たると思われる。

相手と接着剤になるネタの上手な見つけ方

共通の話題を作ることは、一緒の時間を共有している感覚になる。

共通項の見つけ方

  • 例え話
  • おもしろかったこと
  • 週末の過ごし方

全体感想

振り返ると、事実と意見をわけて説明することが重要なことに思える。
説明を聞く時は、事実がなんなのか注意する必要がある。
説明する側は、事実と意見を明確に分ける。
厄介なのは、事実に意見を混ぜてくる輩が多いこと。
新聞やニューズを一つ見ただけで満足するが、かなり危険だと感じるようになったのは、事実と意見を区別できるようになったからかもしれない。
多読は、やっぱり重要。
説明する側もされる側も、事実と意見を意識することの大切さを感じた。

やはり、説明はシンプル化が重要。
物事すべてにおいて、シンプルな方が、人間にはわかりやすい。
結論として、この本では、シンプルがコツだよってことでいいのだろうな。
ソフトウェア開発も一緒。
仕様書も、相手への説明になる。
理科系文章の書き方が、仕事でとても大切。
コレを読んでいた時期は、下記の本も読んでいて、文章術の参考になった。
一度目を通してもらえればと。

suzaku-tec.hatenadiary.jp

【書評】理科系の作文技術

理科系の作文技術(リフロー版) (中公新書)

理科系の作文技術(リフロー版) (中公新書)

目次

  • 序章
  • 準備作業(立案)
  • 文章の組み立て
  • パラグラフ
  • 文章の構造と文章の流れ
  • はっきり言いきる姿勢
  • 事実と意見
  • わかりやすく簡潔な表現
  • 執筆メモ
  • 手紙・説明書・原著論文
  • 学会講演の要領

感想

あくまで個人が呼んで解釈した内容。
実際にかいてあるわけでは無い。
個人の主観も一部混じっている。

準備作業(立案)

理系の文章

理系の文章は、必要上かくか、書かされるもののどちらかにあたる。
だから、書き始める=理論的推察は完了し、書くために必要な材料は揃っているハズ。
材料がない場合は、そもそも各段階にまで至っていない。 始めても失敗するだけなので、書き始める前に、必要な材料があるかは確認する。

理系の文章は、必要とされるから書くため、読み手(書けと支持した相手)が何を欲しているのか考える必要がある。

主題の選定

主題で、文章が有意義になるかが決まる。 下記のポイントを考慮する。

  • 議題は明確か?
  • 一文章一主題になっているか?
  • 長すぎてないか?(ラノベタイトルみたいになってないか?)
  • 読み手の能力を意識した内容
  • 生の情報
    • 自信の考えがあるか?
    • 未熟・浅薄でもオリジナリティは強力

材料となるもの

  • 思いついたままのメモ
  • 5W1Hの情報
  • 図・表
  • 文献

文章の組み立て

  • 起承転結
    重要なことは後で主張
  • 重点先行主義
    重要なことは戦闘で簡潔にまとめて、目に付きやすくしてある。
    新聞がこの手法で書かれていることが多い
  • 序論・本論・結び

パラグラフ

パラグラフとは、文章の段落のこと。
バラグラフを満たす条件は、トピック・小題について、一つの意見を述べてあること。

はっきり言いきる姿勢

日本人が明言を避けたがるのは、文化・環境の違い。
異民族が少ないので、自己の主張を強くするより、相手の主張を取り入れたように見せる動きが長年続いたから。

あいまい言葉は、逃げ道なので、なるべく使わない。
一言一句、責任を持って表明することが大事。

事実と意見

事実とは、証拠による裏付けができるもの。
意見とは、人が下す判断。

レポートを書く際は、意見ではなく、事実を書くことが必要になる。

意見の概念

  • 推論
    前提にもどつく推理の結論
  • 判断
    物事のあり方、内容、価値を見極めた考え
  • 意見
    自分が考えて到達した結論
  • 確信
    疑問の余地がない考え
  • 仮設
    真偽は明確ではないが、仮に出した考え
  • 理論
    証明できそうな事実はあるが、万人に容認させられていない考え

事実の記述で注意すべきこと

  • 本当に必要なものか?
  • 明確に書く
  • 名詞と動詞で書き、修飾子は避ける。
    なぜなら、就職後に意見が混入しやすいから

わかりやすく簡潔な表現

文は、なるべく短く書くようにする。
長い文章は、誤読を招きやすく、読みにくい。

短く書くときの心得

  • 書きたいことを1つずつ文にする
  • 一文の前後関係を考慮してつなげる
  • 主語をはっきりさせる。

簡潔に

簡潔に書くとは、単に短く書くことではない。
必要なこと以外を書かないようにすることである。
一語一語に役割を必ず持たせる。

読みやすさへの配慮

字面の白さ

漢字の濃度を気にする。
漢字は、たしかに見たときにイメージしやすいが、多用すればいいというわけではない。
情報過多を引き起こすため、使う場所は気をつける。
個人的には、接続後に使うのは辞めたほうがいい気がする。
~の為、~故とか。
中二病をこじらせ中かな?って思ってしまう。

漢語・漢字

難しい漢字は、なるべく使わないほうが読みやすい。
(「憂鬱」は、難しい漢字に入るのか、疑問。)

受け身の文

少ないほうが文が短く、主語が明確になる。

並記の文法

並べてくことは、読者に同格の内容が続くことを知らせる。
そのため、予見して読むことができるので、読みやすくなる。

文章の中の区切り記号

  • ピリオド
    文章の終わり
  • コンマ
    読点
  • セミコロン
    文章の終わりを強くアピる
  • コロン 詳細の要約・説明に使うことがある
  • なかぐろ
    並列連結を表す
  • ダッシュ
    コロン、カッコの代わり。説明に使う
  • リーダー 以下省略
  • カッコ

文末の述語

「である」より、「だ」の方がいい。
「である」は、表現的に固い。

執筆メモ

メモを書くときに必要なもの

  • 日付
    いつ書いたのかが重要になることがあるため
  • 辞書
    言語の厳選をするため。ポケモンの厳選よりは楽。
  • 単位・量記号
    共通認識確率のために、なるべく書く
  • 文献引用
    出所を明示しておかないと、あとで著作権の問題になるから。

全体感想

かなり前に書かれたせいか、表現が堅苦しい&コロン・コンマが凄く見づらい。。。
内容自体はいいんだけど、現代用に変えた方がいいのでは無かろうかと思う。
やっぱり、縦書きだろうが横書きだろうが、句読点は「。」「、」の方が見やすい。

執筆メモのあたりは、たしかにそうだけど、実践が難しいって思った。
ぶっちゃけ、メモなんてほとんど取らんしな。。。
もっと使いやすいメモ帳があればいいんだけど。。。
誰か出してくんないかな?
Evernoteだと、有料になっちゃったし、使いたくないんだよね。。。
文房具で、何か決定的なメモアイテムが欲しい。

Firefox54 アップデート機能内容まとめ

Firefox 54 for developers - Mozilla | MDN

提供開始日

2017 年 6 月 14 日

更新内容

公式サイト

詳しくは、公式サイト見たほうが正確

https://www.mozilla.jp/static/images/firefox/logos/header-logo-wordmark.png

目立った変更内容

Electrolysisが全ユーザーに対して有効化

条件を満たしていればデフォルトで有効化されるが、対応してないアドオンが一つでもあると無効になる。
自分は無効化されてしまいました。。。

確認方法は、Firefoxのアドレスバーに「about:support」と入力し、トラブルシューティング情報のページを開く。
※もしくは、メニューの「ヘルプ」→「トラブルシューティング情報」からでも可。
マルチプロセスウィンドウの項目が “0” でなければ有効になっている。

どのアドオンが問題になっているのかを確認するには、「Add-on Compatibility Reporter」を使って確認できる。

Add-on Compatibility Reporter :: Add-ons for Firefox

詳しいやり方は、下記のサイト参照

Firefox 54で全ユーザー向けに導入されたブラウザ高速化技術「Electrolysis」がオンにならない場合の対処法 - GIGAZINE

今回のリリース

マルチプロセスが目玉みたいだね。
メリット享受できてないのが痛い。。。
早めになんとかしよう。

参考サイト

コンテンツのマルチプロセス化を初めて導入した「Firefox 54」が正式版に - 窓の杜

マルチプロセス技術「E10S」を導入した「Firefox 54」リリース | OSDN Magazine

Firefox 54がリリース - 高速なマルチプロセスモデルへの移行が完了