kazutomoのブログ

たまーに気が向いたらなんか書きます

例え話をしないC言語のポインタの説明 のマネ

givemegohan.pigboat.jp

に触発されたエントリです。
読んでてなんかしっくりこないなあ。と思ったので、私なりに書いてみようと思います。

メモリとは

ポインタを理解するためには、上のエントリの通りまずはメモリを知る必要があります。

メモリとは一時的な記憶領域で、ハードディスクやSSDとは違い電源を切ると消えてしまう性質があります。
その代わり、ハードディスクやSSDよりも高速に読み書きが出来る。という特徴があります。

パソコンやスマートフォンでは、ハードディスクやSSDのような記憶領域から必要なデータを読み込んで配置してプログラムを実行するのに使用します。

f:id:kazutomo:20180201152119p:plain

コンピュータは 0/1 で処理される。とよく言われます。
一般的なメモリでは通電しているか、していないかで 0/1 を表現します。

単位として バイト/ビット という単語を聞いたことがあると思いますが
上の図で言うと、0/1 ひとつひとつを表現するために必要なデータサイズを 1ビット と呼びます。
そして、8ビットあつまると、1バイトと表現します。

メモリは4GBや8GBといった単位でコンピュータに内蔵されていますが、
4GBの場合は 4,294,967,296 バイト = 34,359,738,368 ビットのデータを保持出来る。ということになります。

メモリにデータを配置する場合や読み出す場合は メモリアドレス=メモリ上の住所 を指定してアクセスすることになります。
メモリは一次元的に続くデータ領域で、1バイト目を0番地。2バイト目を1番地 というように呼びます。

コンピュータが実行するプログラムデータや、プログラムが動作するために必要な一直なデータなどは全てこのメモリのどこかに配置されて実行されることになります。

ポインタとは

ポインタとは、ずばり メモリアドレス のことです。
例えば、プログラムで 1バイトのデータを保持する data という領域を確保したとしましょう。

これがメモリのどこに確保されるのかは実装方法により、スタック領域やヒープ領域といった場所から確保されますが、今回の趣旨からは外れるので詳しくは語りません。
とりあえずメモリのどこかに1バイトの空間が確保されます。

そして、data というデータを確保したメモリアドレスが data のポインタということになります。

たとえば、data は メモリアドレス1番地に配置されて 3 という数値を格納したとすると以下の図のようになります。

f:id:kazutomo:20180201153351p:plain

この場合、C 言語的に言えば data(dataの中身) は 3 であり、&data(データのポインタ) は 1になります。

なぜポインタを使うのか

たとえば、data を受け取って data を 1増やした値を返すプログラムがあったとしましょう。

uint8 addOne(uint8 data) {
  return data + 1;
}

プログラム的に書くとこんな感じです。

この程度のプログラムの場合、近代的なコンパイラを使用すると最適化されてこのようなことは起こらないと思いますが、原始的に考えると

uint8 data = 3;
data = addOne(data);

というプログラムを書いた場合、3を設定した data と addOne の中の data は別のメモリアドレスが割り当てられ、addOne の中の data には 3を設定した data の内容がコピーされて実行されます。

今回 data のサイズは1バイトという非常に小さいデータだったので、それほど気にする必要は無いでしょうが、もっと大きなデータだった場合、データをコピーするのにかかる時間が勿体ないです。

最終的に 3を代入した data が 4 になってほしいわけですので、ここでポインタを使用します。

void addOne(uint8* data) {
  *data += 1;
}

uint8 data = 3;
addOne(&data);

こうすると、addOne は data のメモリアドレスを受け取って、
*data(dataポインタが示すメモリの中身)に1を加算する。ということになり、
メモリの内容をコピーせずに同じ処理を実行出来ました。

 

このように基本的にはポインタは例外の無いC言語で戻り値はエラーコードに使用し、関数の副作用は引数で受け取ったポインタの実体に対して行うために使われることが多かったです。

 

iPhoneX を修理に出すために iPhone7 に戻って感じた iPhoneX の真価

iPhoneX を落としてしまって、画面にヒビが入ったので Apple Store に行きました。

どうせ交換ですぐ終わるでしょ。と思ってたら、店舗内で修理するので3時間待ってくれ。と言われたんですね。
てっきり数分で新品が出てきて帰れると思ったので、その後予定を入れており 仕方なく修理は諦めて帰ることにし、郵送で修理に出すことにしました。

で、数日後に iPhoneX を集荷に来るので、iPhone7 に戻して半日経ったのですが、体感したのは iPhoneX は想像以上に良くなってた。ということ。

タスク切り替え超便利

こちらのツイートにあるように、iPhoneX は画面下部をスワイプすることでタスク切り替えができるんです。
これによって、ホームボタンをダブルクリックして起動するタスクメニューは殆ど使いませんでした。
※ ちなみに、iPhoneX のタスクメニューは画面下部を長押しなのでテンポが悪いという理由もあります

よくニュース記事とかで印象的な部分をコピーしてLINEやSlackで送信する。ということをするので、タスク切り替えがスマートだと捗るんですよね。

FaceIDはなんだかんだ言って便利

寝起きで死んだような顔をしてるときやあくびをしながらだと認証が通らないFaceIDですが、それでもやっぱり便利と感じることがあります。

たとえば、手を洗った直後に TouchID は通らないことです。
指に水滴が付いていると認証が通らないので、頑張って指の水分を拭き取ってから認証したりするのは顔認証し直すのに比べたらちょっとアホらしい感じがします。

次に、復元直後でローカルのデータストアにパスワード情報がないからだと思いますが、iCloudキーチェーンからパスワード情報を取り出すときに指紋認証を求められるのも、いちいち指をホームボタンに運ぶのにモヤッとします。

バッテリーの持ちが段違い

iPhoneX になって画面上部のバッテリー残量にパーセント表示が出来なくなったのが困るなあ。と思ってたんですが、
使い始めてみると、バッテリーメニューで 使用時間 と スタンバイ 時間が1日で数時間しか変わらない超ヘビーユーザな私でも、20%を切りました。というダイアログは出張時にテザリングしまくったときとかゲームをしまくってる時しか見ませんでした。

だいたい毎朝1時間ほどかけてSNSやニュースを確認したり、いくつかのゲームのルーチンワークをこなしてから仕事を始めるんですが、このときiPhone7では20%ほど消費しているのに対して、iPhoneX では 10% ほどしか消費しません。

 

iPhone7 に戻したときは、iPhone7 の方が軽いし、このまま iPhone7 で定住する可能性あるなあ。とおもってたのですが、意外にももう iPhone7 には戻れない体になっていたようです。

余談ですが、Webから配送修理依頼を出すと Apple Pay 用のウォレットが初期化されるようですので注意してください。
私は Apple Store を出てすぐに配送修理依頼を出したせいで、帰りに Suica 消え去ってる上に、あたらしく登録し直すことも出来ずに久しぶりに紙の切符を買う羽目になりました。

2017年放送アニメおすすめ10選

早いもので、今年もあと数日を残すのみとなりました。

アニメの方も今クールの放送が次々と終わっていき、そろそろ2017年の総括をしてもいい時期だと思いましたので、
私が見てきたアニメの中からおすすめ10選をご紹介したいと思います。

★★★☆☆

サクラダリセット

咲良田という町が舞台で、この町にいると誰もが何かしら特殊な能力を持っている。でも咲良田をでると能力は無くなり、能力があった記憶もなくなる。という設定。

主人公は「一度見たものを忘れない」という能力を持っており、ヒロインは「最大3日前までセーブした時間に時間を巻き戻せる」という能力を持っている。

この能力の組み合わせにより、ヒロインがリセットをしても、主人公はリセット前の記憶を持っている状態となるため、それを使って未来を変えていく。というのが主軸となる。

台詞回しがいちいち中二病くさいのが鼻につくし、中盤までは設定の掘り下げばかりで話のゴールが見えてこないのでちょっと辛いのですが、中盤あたりから面白くなってくるタイプの話でした。

 wwwsp.sagrada-anime.com

 ナナマルサンバツ

クイズを題材としたアニメです。

ヒロインの声優が棒読みと不名誉な形で話題になってしまったのですが、ほんとに棒読みです。

ですが、作品としては面白いので声優の棒読みだけで評価されないのはちょっと可哀想です。

とくに物語としてひねったところは無く、少年マンガらしい王道スポ根ものですが安定した面白さがありました。

7o3x.com

ゲーマーズ!

いつもの感じのラノベ原作アニメなんでしょう?という感じで見ていたのですが、いい意味で裏切られました。

主要登場人物が5人のラブコメものなんですが、アンジャッシュのコントのように会話がかみ合わないことから関係がもつれ続ける。というのが意外な展開でした。

www.gamers-anime.com

★★★★☆

異世界食堂

基本的に私はストーリーものが好きなのですが、日常ものでもときどき刺さるものがあります。

本作は名前の通り、なぜか異世界の各地に主人公が営む食堂の入り口の扉が出現してしまった。という設定です。

異世界人からすれば、食堂のメニューは見たことが無い料理であり、さらに異世界の食事より工夫が凝らされた美食である。ということになっています。

毎話いろいろな異世界の住人が食堂への扉をみつけて、食堂に迷い込み、おいしいものを食べて帰って行きます。

ただそれだけの話なので、肩肘張らずに気軽に見ることが出来ます。

isekai-shokudo.com

幼女戦記

転生もので、第一次世界大戦(風)の時代に幼女として転生した主人公。

記憶はばっちり残っているので、幼女だけど戦術に長けた軍師様として活躍します。

中盤まではかなり良かったんですが、尻すぼみだったかなあ。という印象だったので、

評価は低めになっていますが、中盤までの面白さはピカイチだったので、おすすめです。

youjo-senki.jp

幼女戦記(1) (角川コミックス・エース)

幼女戦記(1) (角川コミックス・エース)

 

3月のライオン (二期)

将棋を取り扱った作品です。史上5人目の中学生プロ棋士が主人公で、プロになってしばらく経ったところから物語が始まっています。

そのため、主人公の過去について、読み手の知らない情報がたくさんあることを武器としたストーリーが描かれます。

この作品は、将棋を軸に扱っているのですが、そこから生まれるストーリーの大半は人間ドラマであり、スポ根とは少々異なります。

基本的にジメッとした人間ドラマが続きますので、苦手な人は苦手かもしれません。詩のような話が見たい。という場合はおすすめです。

3lion-anime.com

十二大戦

干支をモチーフとした12人によるバトルロワイヤルもの。

それぞれのキャラクターに特徴的な能力やバックグラウンドがあり、

バトルロワイヤルものとしてはバトルはあっさりめでキャラクターのバックグラウンドを軸に話が展開する。

最終回の手前まではわりといい感じだったんだけど、最終回がなんだこれ?って感じだったのが残念。そこまでの流れはおすすめです。

12taisen.com

十二大戦

十二大戦

 

★★★★★

昭和元禄落語心中(二期)

タイトル通り、落語家の人生を描いた作品です。

これは二期通してひとつの作品だととらえてこのおすすめ度です。

rakugo-shinju-anime.jp

昭和元禄落語心中(1) (ITANコミックス)

昭和元禄落語心中(1) (ITANコミックス)

 

ボールルームへようこそ

社交ダンススポ根ものという珍しいジャンルです。

この手の作品の主人公は、読み手とスタートラインを合わせるため、

遅れて習い始めるけど、短期間で成果を上げていく。というものが多いですが、本作もその部類です。

ダンステクニックによる成長。というよりは人間性の成長に軸を置いており、苦悩しながらも成長していく姿は応援したくなります。

ballroom-official.jp

メイドインアビス

こちらは、過去に別途エントリを書きました(ネタバレ無し)ので、そちらを見てもらうとして。

アビスと呼ばれる大穴を冒険するファンタジー作品です。

ハードモードにレベル1で特攻するような無謀さと、それによる予想不能な展開が見物です。

miabyss.com

kazutomo.hatenablog.com

 

来年も面白い作品に出会えるといいな!

iPhoneX を買ったらまず設定したい色域設定

iPhoneXを買ったんですけど、OLEDが黄色いんですよね…。

truecolorを切ると良くなるんですけど、OLEDは同じ色を出し続けると焼き付くので、
それを回避するために環境光にあわせて色を変えるというアプローチをとってるわけなので、それは生かしたいですよね。

 では、どうするか?というと、色覚異常対応の機能を使います。

f:id:kazutomo:20171105003804p:plain

f:id:kazutomo:20171105003816p:plain

f:id:kazutomo:20171105003830p:plain

f:id:kazutomo:20171105003856p:plain

f:id:kazutomo:20171105003907p:plain

ここで、青みを付けることで黄色っぽく見えるのを修正することができます。

スタンドに置くだけで充電できる無接点充電器が2000円強で買えるので、デスクにおいてみてはどうでしょう?

【ネタバレ無し】メイドインアビスを見て/読んで震えたので、紹介したい!

メイドインアビス(1) (バンブーコミックス)

実は、前期アニメの中でメイドインアビスは3話切りしてました。
ですが、振り返って、前期アニメの評価を確認してみたところ、メイドインアビスの評価が明らかに光っていたので、週末に見ました。

世界観は面白そうだとは思ったのですが、設定の重厚さに対してキャラクターがゆるふわ過ぎて、生かし切れないんだろうな。というので期待せず切ってしまっていたのですが、完全に期待を裏切られる形でした。

世界設定

とある島が舞台で、その島の中心には大穴が空いています。この大穴はアビスと呼ばれています。
アビスは不思議な世界で、見たこと無いような原生生物などがたくさんいます。
穴自体もすごく深くて、まだ底を見た人はいません。

しかも、アビスにはアビスの呪いと呼ばれる不思議な現象が発生し、上昇負荷とも呼ばれます。
アビス内で下に下る分には何の影響も無いのですが、アビス内で上に上ると様々な症状が体を蝕む。というものです。(つまり、帰り道がヤバい)

1層:軽い目まいと吐き気
2層:重い吐き気と頭痛、末端の痺れ
3層:二層に加え、平衡感覚に異常をきたし、幻覚や幻聴を見る
4層:全身に走る激痛と、穴という穴からの流血
5層:全感覚の喪失と、それに伴う意識混濁、自傷行為
6層:人間性の喪失もしくは死
7層:確実な死
深界極点:詳細不明

アビスに入れるのは探掘家のみで、探掘家もランク分けされており、ランクによって色の違う笛を持つ。
ランクによって潜れる深さが決まっており、最高ランクの白笛でも基本的に5層までしか潜らない。
5層以下に潜るときはラストダイブと呼ばれており、帰ってきた人はいない。

帰ってきた人がいないのに情報があるのは、気球のようなものを使って情報を発信しているから。(それも原生生物に阻まれて殆ど届かないんだとか)

キャラクター設定

リコ:
めがねの女の子。孤児院で育てられている。
孤児院での生活費はアビスで採掘した遺物を売って立てており、
リコは赤笛と呼ばれるランクで、1層まで潜ることが許されている。
母親は有名な白笛で、10年前にラストダイブをした母を探すためにアビスの深層を目指す。

レグ:
ロボット?の男の子。1層でリコが原生生物に襲われているのを助けた。記憶喪失。
手がワイヤーですごく伸びるし、手のひらからビームみたいなの(火葬砲)が撃てる。
なので、リコにはロボットと言われているが、人間性も高くロボットなのかは未知。
アビスの呪いの影響を受けない。

基本的に主要キャラクターはこの2人のみです。
孤児院の友達や、他の探掘家も出てきますが、この二人で深層を目指すことになります。

みどころ

思った(キャラデザの印象)以上に本格的で容赦の無い冒険。
アニメだと後半のエピソードなんかは、いろいろと唸らされるものがあります。

アニメでは原作4巻の前半までを映像化しており、原作は6巻が7月にでたところです。
ここからもわかるように、アニメは一区切りついているものの、まだまだ冒険の途中で終わってしまいます。

アニメを見たら、原作が読みたくなるのは必至。私も原作を買って一気に読んでしまいました。
アニメは非常に原作に忠実に描かれており、一部改変もあるのですが、それはそれで脚本家の意図が透けて見える変更で、すごく丁寧に作られています。
特に、アニメ化されたエピソードのハイライト部分が、マンガだとばーっと駆け抜けてしまっていた印象があったのですが、アニメだとかなり丁寧に時間をかけて演出されており、より感情移入できるようになっており、原作を補強する存在として非常に良くできていました。

さいごに

Amazon Prime Video でアニメは全話見れますので、アニメから入るのもいいでしょうし、
原作の巻数もまだ少ないので、原作から入ってもいいと思います。
とりあえず名作なので、お時間が取れるようであれば是非読んでみてはいかがでしょうか。

 

メイドインアビス 2 (バンブーコミックス)
 

 

 

第一言語をJavaからKotlinにした日

私が仕事として扱ったことのあるプログラミング言語は以下があります。

この中でも Java は特別で、15年近く愛用してきました。

Javaの優れている点

Java の優れている点として以下があるとおもいます。

信頼性の高いVM

インタープリタ言語の中にはランタイムのバージョンアップで動作が変わってしまったりすることも多く、なんたらenv といったアプリケーションを使って任意のバージョンのランタイムに固定するのが慣例となっていますが、Javaにおいては最新のJVMを入れれば大体なんとかなります。

クロスプラットフォーム動作

私は長らく Windows を開発機として使用し、Linux サーバで動作させる。ということをしてきましたが、Windows で動くけど Linux で動かない。という経験はしたことがなく、動作させるOSによって動作確認をやりなおす。というような手順を踏んだことはありません。
現在では開発機として Mac を使用していますが、その際も状況は変わっていません。

インタープリタ言語の中には高速化のためにネイティブコードをコンパイルして使用するものが多く、Windows でビルドした成果物を Linux に持っていってもアーキテクチャの違いによって動作しない。といったことが起こりえますが、Javaにおいては変なことをしなければそのようなケースはありません。

豊富なライブラリ群

これは今では多くの言語で豊富なライブラリを所有しているので、多くの場合はあまり差とは言えないかもしれません。
しかし、Java は現在も重要なポジションをしめており、多くの場合に優先してSDKやライブラリがリリースされる言語でもあります。

高速動作

Javaで記述されたプログラムは非常に高速に動作します。
また、スレッドを使って作成されたプログラムはマルチコアで動作します。
多くのプログラミング言語のランタイムがシングルコアでしか動作せず、プロセスフォークによってマルチコアに対応するしかない点を考えても、ここはかなり優位点といえます。

Javaのイマイチな点

Javaは多くの優れている点を持っているとはいえ、当然ながらイマイチな点があります。

  • ランタイムがでかい
  • VMがあたたまるまで時間がかかる
  • 言語仕様が堅い
  • NullSafety ではない
  • ストリーム処理がダサい

ランタイムがでかい

これは C/C++golang のようなネイティブコードを出力するプログラミング言語に対してのイマイチな点です。
ランタイムによって多くの恩恵を得ているのでやむを得ない面もあるのですが、省メモリ・省ディスクスペースを要求されるケースではJavaが使用できないことにつながっています。
たとえば、ニンテンドー3DS の OS 開発をした際には C++ で開発しましたが、これはJavaの入り込む余地のない世界といえます。
特にメモリの面は問題として大きく感じており、Hello World を動かすだけでも数MBのフットプリントが必要で、これはおそらく全プログラミング言語の中で最大レベルなのではないでしょうか。

VMがあたたまるまで時間がかかる

私はこの数年間 AWS Lambda を使用したアプリケーション開発を中心に仕事をしていますが、AWS Lambda でも仕様上は Java は使用できるのですが、現実的には使用できない。と感じています。
これは AWS Lambda のコールドスタート時に特に体感します。コールドスタート時にはLambda を実行してから、実際に処理が動き始めるまで約7秒の時間を要します。
それに対して、Python は100ms前後です。この差によって私は開発言語を Python にせざるを得ませんでした。

しかし、多くの場合はプログラムの起動に7秒かかろうと気にならないことのほうが多いでしょうから、これはサーバレスアーキテクチャにおける特殊なニーズといえるかもしれません。

言語仕様が堅い

Java はとにかく堅い言語です。
その堅さは多くの場合にいい結果をもたらします。
たとえば、冗長なまでの型宣言ですが、他人の書いたプログラムを見る際には、どのオブジェクトにどのような値が入っているのかすぐに特定できます。

  1. public function hoge($fuga)
  2. {
  3.   $this->fizz($fuga->piyo);
  4.   return $this->buzz($fuga->piyopiyo);
  5. }

PHP にありがちなこのようなプログラムを見つけたときの絶望感は Java で味わうことはないでしょう。
$fuga は何者なのか、hoge の戻り値は何なのか? Java であればドキュメントがなくてもソースコードによって明示されています。

一方でこの堅さは悪い面にも作用します。

もっとも揶揄されるのが Getter/Setter でしょう。
Java で開発をする上で、

  1. private String hoge;
  2. public String getHoge() {
  3.   return hoge;
  4. }
  5. public void setHoge(String hoge) {
  6.   this.hoge = hoge;
  7. }

このようなコードがあちこちに現れることを許容しなければならないでしょう。

NullSafety ではない

ぬるぽ というスラングが生まれる程度に null にまつわる不具合は多いです。
Java もこれに対して抗おうとこの値はnullかもよ?という Optional 型を導入するなど努力はしています。

しかし、null が設定されうる Optional 型など何の役にも立たちません。

  1. Optional<Hoge> nullValue = null;
  2. if(nullValue.isPresent()) { // ここでぬるぽ
  3.   nullValue.get().fuga();
  4. }

Java が本当にぬるぽ問題に対して本気で取り組む姿勢を見せるのであれば、Optional でない型には null が設定できないようにしなければならなかったのでしょうが、10年前のコードでも動くJavaのバージョンに対する良さが失われる破壊的な変更になりますので、それは避けなければならなかったのでしょう。

ストリーム処理がださい

Java でもコレクションに対するストリーム処理ができるようになりました。

  1. List<String> itemNames = items.stream()
  2.   .map(Item::getName)
  3.   .collect(Collectors.toList());

以前の foreach を使った実装に比べれば100倍ましなのは事実なのですが

.stream() とか .collect() とか所々ダサいです。

前述の Optional型 によって、さらにこのストリームはだささを増します。

  1. Optional<Item> item = items.stream()
  2.   .filter(item -> item.getId() == 1000)
  3.   .first();
  4. if(item.isPresent()) {
  5.   item.get().action()
  6. }

そして Kotlin

Kotlin は JVM で動作し、Java と混ぜて使用できます。
これによって、多くの Java の資産をそのまま受け継いで使用できます。

にもかかわらず、Java のイマイチだった点を改善し、より使いやすい言語仕様にまとめあげています。

Getter/Setter

  1. class Hoge(
  2.   val fuga: Int
  3. )
  4. val hoge = Hoge(1)
  5. print(hoge.fuga)
  6. hoge.fuga = 100 // エラー: fuga は不変(val) 宣言なので書き換えられない

さらに Kotlin ではC#のプロパティメソッドのような機能も使用できます。

  1. class Hoge(
  2.   val fuga: Int
  3. ) {
  4.   val fuga2pow
  5.     get() = Math.pow(fuga.toDouble(), 2.0)
  6. }
  7. val hoge = Hoge(1)
  8. print(hoge.fuga2pow)

.toDouble() のあたりにダサさを感じざるを得ませんが、Kotlin の設計思想として暗黙の型キャストは if(variable is Class) で判定したときにしか作用しないという方針のようなので、ここは諦めるしか無さそうです。

NullSafety

Kotlin ではデフォルトではオブジェクトに null を代入できません。
つまり、プログラム側では null チェックなどせずに安心してオブジェクトを触れます。

逆に null が入っているかもしれないときは Hoge? という型で宣言することで、Hoge型だけど null がはいっているかもよ?と宣言します。

そして、Hoge のメソッドを触るときには hoge?.action() と呼び出せば、hoge がnullでなければ actionメソッドを呼びだす。という実装になり、null チェックもダサくありません。

ストリーム処理

  1. val itemNames = items.map(Item::name)

 

  1. val item = items.filter {
  2.   item -> item.id == 1000
  3. }.firstOrNull()
  4. item?.action()

Java でダサかった部分がかなり改善されて、理想的な形になっています。

ランタイムがでかい / JMがあたたまるまで時間がかかる

このあたりは JVM の問題ですので、JVMベースの Kotlin では解決できません。
しかし、Kotlin は ver1.1 で javascript をランタイムとして動作できるようになりました。
さらに Kotlin/Native というプロジェクトでは Kotlin で書かれたプログラムをネイティブコードにコンパイルする開発が進んでいます。
近い将来、組み込み開発にも Kotlin を使用できるかもしれません。

現在では開発する対象に合わせて開発言語を選定していますが、
Kotlin を使っておけばなんでもOK。となる足音を感じています。

 

すくなくとも、現時点でも Java の代わりに Kotlin を使用する。という面においてはメリットしかありません。
そのため私は第一言語としてのJavaを捨て、Kotlin に乗り換えることを決めました。

 

Kotlinスタートブック -新しいAndroidプログラミング

Kotlinスタートブック -新しいAndroidプログラミング

 

 

FF14 紅蓮のリベレーター(4.x)対応 吟遊詩人スキル回し

オメガ零式が開いて早速突撃してきたんですが、平均IL317なのにいまいちDPSが出ていない…。木人を殴っても倒せない…。
なんかおかしいんじゃないか?ということで、4.0になって全体的に変わってしまったスキル回しを改めてイチから見直したので、まとめておきます。

フローチャート 

f:id:kazutomo:20170719131852p:plain 

実際にこれで木人をしばらく回しましたが、リフルジェントアローのあたりが安定しないので、エンピリアルアローで乱れ撃ちを使ったほうがいいのかも。

賢人のバラード → 軍神パイオン → 旅人のメヌエット

基本的に歌は切らしてはいけない。リキャスト80secなのでちょっと早めに切り替えても回るけれど、詩心がたまった後半は1秒でも長く使いましょう。

旅人のメヌエット

ピッチパーフェクトはなるべく詩心が3スタックするまで我慢。

 

 

トームバイト → コースティックバイト → アイアンジョー

DoTは切れるとすごくもったいないのでなるべく切らさないように頑張る。
DoTを維持する自信がない場合はサイドワインダーは連打マクロに入れないほうがいい。

ストレートショット

ストレートショットのバフはクリティカル率10%アップで、
上記歌の詩心がつく条件がDoTでのクリティカル発生なので、DoTを切らさないこととこのバフを維持することが肝となります。 

連打マクロ

連打マクロには独立したクールダウンを持つものを押し込みました。
ブラッドレッターを入れていますが、IDなどで雑魚が沸く場合はレイン・オブ・デスとタイマーが共有なので入れないほうがいいかもです。
少なくともオメガ零式一層に関してはここでも問題ないかと。

ストレートショット効果UP

ヘヴィショットでストレートショット効果UPがProcしたらストレートショットではなくリフルジェントアローを撃つ。言わなくてもわかると思うけど。
乱れ撃ちを組み合わせると三倍界王拳になるので、リキャストしてたら使う。

その他

バトルボイス

空気を読んでみんなが攻撃できるときに歌う

地神のミンネ

やべー攻撃に合わせてMTに打つ
ギミックの処理でダメージを受けるDPS/ヒーラーでも可

オメガ零式の場合はツインボルトでMTに合わせるのが良さそう。
バフをたいてて大丈夫そうな場合はミールストームに合わせてもいいかも。

パリセード

やべー攻撃に合わせてMTに打つ
ギミックの処理でダメージを受けるDPS/ヒーラーでも可

オメガ零式はどの攻撃が痛い物理かまだ見極められてないっす

トルバドゥール

どれがいいのかわかんない。コンテンツ次第な気がするけど
賢人のバラードのHP15%UPにあわせておけば間違いない気がする!

リフレッシュ

ヒーラーの状態を見て打つ
リキャスト時間が長いので、1発めは両方のヒーラーが8割切ってたらもう使ってもいいかも。

バラードと違って使った瞬間に死んでいる場合は生き返っても反映されないので
ヒーラーが蘇生を受けた場合、生き返ったのを確認してからうつ

タクティシャン

みんなのTPをみて打つ
…んだけど、4.0の調整でTPが切れることってあんまりない感じ。