TUT CSCのおはなし
はじめに
この記事は「TUT AdventCalender」の18日目の記事です。
適当にTwitterで流れてきたのを見つけたので埋めました。
何を書こうか悩みましたが、私は大学ではCSCの人なので、CSCについて書いておこうとおもいます。
CSCとは?
これです。CSCと一般に大学内で言うとキャリアサポートセンター(通称キャリクソ)に解決されてしまうので気を付けてください。 卒論ではCSCという単語は使えません。ちゃんと説明して、以後CSCと表記と書かないといけない。
場所は八王子キャンパスのカタケン地下1Fにあるよ。ただ、あそこはたいてい電気ついてない。あそこにブレードサーバとかPCがいくつかあってそれで動いてます。
CSCはなにしてるの?
これの開発、運用をやってる。 といえばたくさんの人に通じる。
ただ学生ポータルはCSCの中ではおまけ案件で、最近の本筋ではないけどね。
あと本学のMoodleの運用もやってるよ。 来年サーバのリプレイスをするらしい。
実際に誰がいるの?
CSの田胡教授が偉い人だよ。
CSの田胡研究室の一部の学生がこのクラウドサービスセンタの開発をやってるよ。
学生はなんかサービスを開発して消えていくものなので、運用に関しては助手?の先生がけっこうやってるよ。
最近はなにしてるの?
人によりやってることが違いすぎるのであれですが、
このでいぷらの教育支援とか(これは田胡研じゃなくてでいぷらの研究室が参画してるはず)
これは私がリプレイスしたのでいまはたぶん動いていないけど、こういうクラウドインフラっぽいソフト作ったりとか
だいぶ昔になっちゃうけど2代目?のポータル作ったりとか
こんなことをしているはず。
学生ポータルについてご紹介する
CSCの昔の人たちが作った、1年のキャリクソでひたすら文句が出る、ポータルについて
- 歴史
- 全体構成
- 動作概要
的なのをご紹介します。 ポータルは基本卒論ネタになっていて情報公開がされているので、私がここに書いても問題はないはず。
ポータルの歴史
今の人はたぶんほとんど知らないけど、ポータルは何回か作り直されています。
昔のPortal
ふるい。 今の1代前のポータルなはず。 卒論から引っ張り出してきた。 今のポータルと基本的にやってることは同じなはず。 あとで説明しようと思うけど基幹部分は同じ。
あとポータルじゃないけどASSITとかいうMoodleの前バージョンもあったんやで。
今のPortal
できたのは多分4年前だと思う。 それ以後はあまり手を入れていない。
今後のPortal
上の方からこうしろああしろって感じのが出ている。 具体的には学内サイトとシームレスに結合しろ。 みたいな感じ。
どうなるかわからないけど田胡研の開発のメインラインになることはないかなぁ?感。
現在ポータルの基本のAPIの整備を研究室の誰かさんがしているのでこれでなんかしていく感じかな?
全体構成とか
卒論を調べればわかるのだが、こんな感じ。 本番のそっくり構成をそのまま載せるのはよくないかなーとおもったので。本番とかなり似た状態のテスト環境の構成を載せる。
随所に闇を抱えている。 闇を説明していったほうが楽しいと思うのでいくつか書いていく。
闇その1: JavaRMI
RMIって知っていますか? リモートメソッド呼び出しのことです。 上の構成図にもありますが、hornetとneptuneってのがDBと通信してるんです。 これはJavaのRMIサーバ側になっていて、ポータルのアプリとかのクライアントはすべてこのRMI呼び出しで名簿とか講義情報を取ったりします。 このhornetとかneptuneは全体の基盤になってる部分なのでそう変えられません。 このRMIサーバ側はJava7で動いています。 なので基本Java7以外使えません^_^
portalが依存しているのは大したこと無いのですが、教務システムとかでもたしか依存しているはずなのでそうそう手がでない。
これは闇。
闇その2: (多分)誰も知らないApacheの独自拡張モジュール
ポータルとかにはシングルサインオンが設定してあります。 グーグルのOpenIDの認証を要求するやつ。 あれはどうやってるかっていうとフロントエンドのWebサーバ(Apache)に独自に開発したモジュールをロードさせて、そのモジュールで追加させたディレクティブで認証を掛けたり、掛けなかったりを制御しています。
このモジュール。 たぶん今ビルドできる人いません。 まぁ大したことやってるわけじゃないんで置き換えるのはすぐですけど。
あ、あとApacheのバージョンも古いです^_^;
これは闇。
闇その3 : フロントとサーバサイドを分離できないJavaServletの上に作られた独自フレームワーク
なんかJavaServletの上に独自に作ったフレームワークをかぶせて現在のポータルは動作しています。 あの当時は良かったかもしれないけど今の基準から考えると厳しい。
時代は変わるもんなんですね。。。。。。
こちらその卒論(修士論文)になります。
あとフロントといえば、CSSはSCSSで書いてあるんだけど、これのプリコンパイルや、JSのミニファイをMavenでやってたりする。
これは闇。
いっぱい闇を抱えてて楽しい。
さいご
今日はTUTのカレンダーということで弊学のCSCのご紹介をしました。 いっぱい闇の紹介をしたのですが、イケイケな後輩がなんかポータルで頑張ってくれるそうなので、来年はぜんぶイケイケな感じになって闇は晴れることでしょう。
私は今日研究室に行ったらボスに「卒論マダー??」って言われてしまったので、CSCのことは何もかも後輩に任せてさっさと卒論を書きます。
おしまい。
Synlogy DS1815+ & WD Red 3TB * 8 (RAID6)のパフォーマンス
今日やったこと
よく寝た。
研究室にNASがきてパフォーマンス測定をしていなかったなーって思ったので、 本格稼働させる前にパフォーマンス測定をすることに。
前回の
と併せて比較できたらいいなーって感じ。
対象ハード
前回のRAID1とは違うある程度速度が出そうな構成。
簡易測定
測定法
前回と同じようにNASにSSHして、シーケンシャルリードとシーケンシャルライトを測る。
# リード for i in [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12];do sleep 10;echo $'\n\n' $i;hdparm -t /dev/mapper/vg-volume_1;done
# ライト for i in [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12];do sleep 10;echo $'\n\n' $i;date;time dd if=/dev/zero of=/volume1/hdparm_write$i.tmp ibs=1M obs=1M count=1024;date;done
シーケンシャルリード
226MB/s
シーケンシャルライト
368.5MB/s
結果
そこそこ速い? 前回から比較すると、リード:178 => 226 , ライト:121 => 368 とそこそこの速度増加。 ライトがなんか速いですね。 まぁこれだけだと単にRAIDにしたら速くなたーくらいなので。 もうすこしちゃんと測ります
まともに測る
今回のNASの利用方として考えているのが、NASからiSCSIを出し、VMのイメージを配置してESXiのホストで動かすことです。 なので、iSCSIでマウントした側でどの程度の速度が出るのか測ろうと思います。 (おまけでNFSも測ります)
測定法
iSCSIのTargetをNASに設定します。 これを適当なVMでマウントします。 その上でシーケンシャルリード、ライト、ランダムリード、ライトを測定します。
VM -NAS間は1Gbpsのネットワークで接続されていますが専用線ではありません。 ある程度の帯域が消費済みと考えられます。
測定ソフトとして
を参考にBonnieというソフトを利用します。
iSCSI結果
Version 1.04 ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP nyanko 31880M 103222 88 120781 13 49122 3 92980 81 124169 3 469.0 1 ------Sequential Create------ --------Random Create-------- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 53691 99 950016 98 126168 101 53265 99 1215241 105 120538 101
NFS結果
NFSのマウントオプションは未指定です。
Version 1.04 ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP nyanko 31880M 105583 87 105032 4 52586 4 100403 89 129458 3 529.1 0 ------Sequential Create------ --------Random Create-------- -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 330 1 27630 11 406 2 340 1 4160 10 537 2
さいご
NASのパフォーマンステストしてたら帯域使い尽くした
— namazu (@namazu510) 2017年12月17日
になって、他のPCのネットが辛くなりました。 ルータとルートハブ間の線を使うようにテスト配線した状態でやったのがよくなかった。
CSSGridとかいう強い奴
はじめに
この記事は、私の所属する研究室のアドベントカレンダー16日目の記事です。
光の速度で執筆を終えないといけない事情があるため内容が薄いですが悪しからず。。。。。。。 昨日に続いて今日も飲み会に行ってきます。
ではさっそく。
CSSGrid?
CSSGridとはCSSの新しいレイアウトモジュールです。 レイアウトモジュールとはおおざっぱに言ってしまえば。
.hoge { display: flat; }
のflatにあたる部分で指定する物です。ここにflex
とかblock
とかinline
とかtable
とか色々と書くと様々なレイアウトが適用できます。
最近ではflex
が非常に強力であるため多く用いられてますね。 これでいつもgridをみんな書いていることが多いはずです。
上のサイトはflexboxでいろいろなレイアウトをするサンプル。 ほんとflexbox有能感。
私は最近このflexboxなしでは段組が出来なくなってしまいました。 ゆとりなので昔のflat
使うやり方は忘れた。
ちょっと前なんですが、このdisplayの所に指定する物として、gridというのが追加されました。 これにより多数の新規プロパティが使えるようになり、gridについて明瞭にCSSで記述することが可能になります。
flexboxは回り込みの制御なのでgridを直感的に組むのが難しかった気がします。 しかしgridはgridを組むためのものなので、特に詳しくなくてもgridなんだなーってわかる記述が書けます。
現時点ブラウザ対応(2017/12/16)
主要ブラウザは対応しています。 とりあえずそのまま使っても開発では検証できるので、ちょろっと作って手元でやってみることができそうですね。
聖杯レイアウトをCSSGridで
聖杯レイアウト?
たまに知らない人がいるんですが、聖杯レイアウトとはこんな感じのレイアウトのことです。 よく見る奴ですね。 gyazo.com
CSSGridで聖杯レイアウトつくる
HTMLはまぁこんな感じ
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>聖杯レイアウトサンプル</title> <link rel="stylesheet" href="./common.css"> <link rel="stylesheet" href="./grid-layout.css"> </head> <body> <header class="header">Header Area</header> <main class="content">Main Content Area</main> <aside class="menu">MenuArea</aside> <aside class="left-menu">LeftMenuArea</aside> <footer class="footer">Footer Area</footer> </body> </html>
common.css
は背景色を付けたりしているだけ。 grid-layout.css
が段組をしているCSSです。
.wrap { min-height: 100vh; display: grid; /* 見た目通りにgridを書く */ /* 縦横3列のグリッドをgrid-areaで名付けた名前で埋めていく */ grid-template-areas: "header header header" "menu content left" "footer footer footer"; /* 縦列の幅を設定 frは利用可能な幅の中で占める割合. */ /* 今回の場合, 1fr = 100vw - (160px * 2) */ grid-template-columns: 160px 1fr 160px; /* 横列の幅を設定 */ grid-auto-rows: 100px 1fr 30px; } /* レスポンシブ対応させる グリッドの組み方を変えるだけでOK */ @media screen and (max-width: 600px) { .wrap { /* 上から横一列縦5行で並べる */ grid-template-areas: "header" "menu" "content" "left" "footer"; /* 列幅 */ grid-template-columns: 100vw; /* 高さ */ grid-template-rows: 100px 50px 1fr 50px 30px; } } /* グリッド内の各要素にgrid-areaで名前を付ける */ .header { grid-area: header; } .content { grid-area: content; } .menu { grid-area: menu; } .left-menu { grid-area: left; } .footer { grid-area: footer;}
結果
良い感じにできてますね。
Flexbox or CSSGrid?
Flexboxで今回と同じレイアウトを組む
やりやすいように微妙にHTMLを変えます。
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>聖杯レイアウトサンプル</title> <link rel="stylesheet" href="./common.css"> <link rel="stylesheet" href="./grid-layout.css"> </head> <body class="wrap"> <header class="header">Header Area</header> <div class="content-wrap"> <!- 横並びのdisplay flexを指定するためこのdivが増える -> <main class="content">Main Content Area</main> <aside class="menu">MenuArea</aside> <aside class="left-menu">LeftMenuArea</aside> </div> <footer class="footer">Footer Area</footer> </body> </html>
3行を組んで2行目をflex入れ子で横に並べる感じで作ります。
CSSはこんな感じです。
/* 縦3列のflex */ /* header -> content -> footer */ .wrap { min-height: 100vh; display: flex; flex-direction: column; } .header { height: 100px; } .footer { height: 30px; } /* 横3列をflex入れ子で作る */ /* menu -> content -> left-menu */ .content-wrap { display: flex; flex: 1; } .content { flex: 1; } .menu { width: 160px; } .left-menu { width: 160px; } /* レスポンシブ対応, 横並びを縦に変える & 高さ設定 */ @media screen and (max-width: 600px) { .content-wrap { flex-direction: column; } .menu { height: 50px; width: 100%; } .left-menu { height: 50px; width: 100%; } }
gridとして作るのを考えるとなかなか分かりにくいですね。 gridモジュールが一括してすべて設定できるのを考えると、flexはいろいろなところに設定が分散してしまって面倒感があります。
さいご
ちょろっとCSSGridを触ってみましたが、Gridレイアウトを作るのには最高って感じでした。
Flexで無理にGridを作っていた感じがなくなり、綺麗に書けるようになった気がします。
がっつり使ったわけではないので、細かく何が出来ないのかとかは分かりませんが、今後積極的に使って行きたいなと感じました。 古いブラウザ対応もプリコンパイラとかでできるのかな?
もっと詳しくやりたかったんだけど今日は時間が無いのでこれでおしまい!!!
研究室のアドベントカレンダー、明日は3年のtachanが書いてくれるそうです。 mrubyをやってみるんだそうです。 なんか強そうな感じがしますね。 ご期待下さい。
参考サイト様
コミケの共同購入支援用アプリを作った話、そして数年運用してみての感想とか。
はじめに
この記事は「ブログ力爆Age Advent Calendar 2017」の13日目の記事です。
同期がやってるこのカレンダー、前年に引き続き今年も参加しました。 去年はVue.jsでSSR(サーバサイドレンダリング)する - Qiitaを書きました。
今年は何を書こうか悩みました。 結局、今年は技術的な物は研究室のアドベントカレンダーでやっているので、ネタ系を書くことに決めました。
コミケ
コミケの時期です。 夏から冬はほんと一瞬でやってきます。 私の場合、優先度が コミケ>>卒論 なので卒論はそっちのけでコミケの準備をしてたりします。
私は海鮮なのでサークル参加はしません。そのうち技術島で出せたらいいかなーなんて思ったりはしますがね。買うのに全力を出します。 年に2回だけ真面目になり、どうすれば可愛いけもみみ本とグッズを集められるのか考えてます。
今年も可愛いけもみみ本がいっぱい欲しい。
コミケと共同購入
広い会場、ちょっと前から東7,8とかいう魔境も追加された中で、10時から11:30分くらい(この辺過ぎると買い逃し率が一気に上がる)までの1時間30分でお目当ての大半を回収して回るのはなかなか難しいものです。
地図を記憶し只ひたすら回る訳なんですが、ホール間移動をすると一気に効率が落ちます。 なので私は身内とちっちゃなグループを組んで上手い感じに回したりしています。
こういった共同購入のグループ中で問題になってくるのが
- 事前の購入希望の付き合わせと担当決め
- サークル回っている最中の情報交換
- 購入後の金銭の受け渡し
などです。
共同購入の支援アプリを作った
高校3年の冬か大学1年の夏の時に色々と大変だったので、支援アプリを作りました。 それ以後ちまちまと作り直したりしながらグループで利用しています。
仕様は、サーバ-クライアント構成のアンドロイドネイティブアプリです。
なんでアンドロイドネイティブかというと、グループにはiなんちゃらとかいう物を使っているアホはいないからです。
どんなものかというと、全員が書き込める買い物リストがあって、そこにサークル単位で担当ユーザを設定でき、購入情報や並んでいる際の状況等を書き込みます。 そのリストが全員で同期されるって感じの代物です。
ちょっと昔の頃のスクショが合ったので貼ります。
サークルリスト↓ 性癖バレしないようにサークル名とか隠したらよく分からなくなった gyazo.com
地図とか
使い方は、
- 前日までに買い物リストに欲しいサークルと品を各自が書き込んで
- 前日の夜に担当を決定
- 当日は自分の担当だけのリストを表示させ、サークルを回り、購入したら購入済みのチェックを付ける
- 撤収時にリストから誰が誰にいくら払えば良いか算出して戦利品受け渡ししておしまい
こんな感じに使います。
誰の欲しいものを誰が買ったかがわかるので、撤収時にワンボタンで金銭計算ができます。
使っての感想
- 買い物中にLINEとか電話とかSkypeとかでひたすらどこ買った?買ってない? をしなくて良くなった
- 紙にひたすら買い物リストをメモらなくて良くなった
こんな点がアプリ化でよくなりました。 まぁ当然か。
これは導入してから気づいたんですが、
撤収時の料金計算が圧倒的に楽になって感動しました。
作る前は計算くらい終わった後だからのんびりやれば良いじゃんって考えだったのに、導入後はこれないと辛くなりました。 撤収時はみんな疲れてるから頭使いたくないんですね。 はやくおうち帰って本読みたいって。
最近の課題
使えば使うほど、無限に課題がでてくるもんです。 最近はこんなのに直面しています。
通信
これは重要な課題。 コミケ会場の通信が最悪。 基本的に通信はぶつぶつ切れることを想定していないといけません。 前々回の東7でほとんど回線が繋がらず、アプリが機能しなくなったことがあり、その際から通信の部分については特に力を入れているのですが、もっとやらないとだめだなーって。 今はキャッシュを使ったり、送信失敗時に極力ユーザの手を煩わせないようにしようと手を打っている程度です。
ちょっとぶっ飛びすぎですが、100人を超える規模のグループであれば、各自のスマホのBlueToothを用いてメッシュネットワークを構築しP2P通信することでコミケ会場中で安定した通信が出来そうです。 こんなのできたらすごいなーって思います。
地図
会場地図が問題、 どうレンダリングすればパフォーマンスが落ちなくて、なおかつ簡単に扱えて、コミケの度に作り直す手間が減るんでしょうかね。 今はエクセル方眼紙で地図を作り、ちょっと加工したCSVを生成、そのCSVからWebViewにロードしてJSでテーブルを構築して使っています。 描画にCPUが遅いスマホだと2秒くらいかかるのが欠点です。 使い勝手&開発しやすさはそこそこ良いのですが。。。
SNS同期
Circle.msやPixiv,Twitterとの同期を入れたいです。 Circle.msと連携すればサークル登録の手間が減少しますし、Twitterはサークルさんが完売報告を行うのでリアルタイム監視は重要です。
登録してあるサークルさんがつぶやいたり、2chのコミケスレに情報がでたらプッシュ通知とか流れるようにとかしたいです。
やれたらなーって言ってることをやる
一番重要な課題。 上に上げたような機能は、時間を掛ければ作れるので、やるかやらないかなんですが、ずっとやってない。
よくない。 なのでやる気を出す方法を考えて実行しないといけない。
さいご
長く使ってると色々と楽しいことがある
この機能を持つアプリを初めて作ったのは高校3だか、大学1年だかだと言いました。なので4年ほど(7,8回のコミケで)このアプリを使っていることになります。
これまで何度か作り直しをしていて、すごく良いことを得たなって思うことがよくあります。
一番始めに作った実装は、サーバ側がJAVAで出来ていて、TCPコネクションをアンドロイド側と貼りそのストリームでJavaオブジェクトをシリアライズし流す形でデータ同期をしていました。
DBなんてものは存在しませんでした。 自分でロックを取りクライアントが送ってくる時間情報と照らし合わせサーバ側のオブジェクトを更新し、クライアントに応答していました。 (頭おかしい)
そんな状態の初版から、ぷよぐらみんぐを学んでいき、DBを利用したり、サーバ側はAPIとして構築するなど進化していきました。
またAndroidも元々ぐちゃぐちゃな実装だったのが、大学3年の夏のリプレイス時にMVP+DDDという設計で固めることに成功し、良い感じに作ることが出来るようになりました。
こういう自分の成長が見られるアプリを持てているのはすごく良いことだなーと感じます。 就職においても長く1つのものを開発してきた経験は武器になりました。
今後は(去年から言っているんですが)Firebaseを使ったり、AndroidもアーキテクチャをGoogleが示したのでそれに乗っ取ったりなどしたいです。 最近はフロントの人であるのでReactNativeとかで組んでもみたいなーと。。。
C93対応さっさとやれ
急いでやります。
おしまい。
後付け
「ブログ力爆Age Advent Calendar 2017」 適当にもふもふかくとかいう枠を取ったせいで昨日の方には変な期待をされてしまいましたが、このアプリでもふもふにゃんにゃんする同人誌を手に入れることが出来るのでそれほど違いはないだろうと自己完結しています。
アドベントカレンダーは明日はかったーくんが書くそうです。 弊研の誇る偉大なるスーパーハカーなのですごい記事を書いてくれるでしょう。 期待しています。 じゃあおやすみ。
なんかかっこいいGPUのはなし
今日したこと
起床ちゃれんじ失敗
— namazu (@namazu510) 2017年12月12日
早速起床チャレンジに失敗。 昼夜逆転しすぎててよくない。 9時頃に嫁に「起きないんですか〜?」って言われた気がするんだけど二度寝の誘惑には勝てなかった。 結果3年生とのミーティングに遅れるっていうよくないことをした。
明日はちゃんと起きたい。
大学に着いたらなんかPCパーツが届いていたのでPCを組んだりした。 GPUとかが来たんですが、なんかかっこよかったので今日はその記事でも書こうと思います。
GPUとか
GPUとそのおまけたち。 研究室では12月頃で年度の発注を終えないといけないので、年度の予算を使い切るためにいろいろなものを買います。
今年研究室ではGPUを買いました。 機械学習とかするんでしょう。
買ったGPUはASUSのGTX1080Ti ピカピカ光るやつです。 同期が発注書を書いたので私は型番を知りません。 これがなんかものすごく冷えるのでおすすめだそうです。
早速適当な研究室の共用ワークノードにぶっ刺してみました。
このマシンは研究室の誰でも使えるCPUマシンという位置づけだったのですが、GPUも刺さってしまったので機械学習も回せる強いマシンになってしまいました。 GPUのディスプレイ出力系には一切何も刺さっていない(保護プラグすら抜いていない)っていうのがなんかいいなって思いました。
このごっついGPUを挿して電源を入れたんですけど、ファンが回りませんでした。 どうやらこのGPUは高温にならないとファンが回らないらしいです。 少し負荷を掛けるとファンの1つが回るなんていう高度なファンコントロールがされていたりします。
なんかファンが止まっているのは仕事してないようでムカついたので、即刻cudaを入れてGPUベンチマーク掛けました。
そしたら
こんな感じでちゃんと回ってくれました。 よく冷えるっていうからホントなのかなーって温度を見ていたら最高で57度程度。 他に持っているグラボは全力稼働させると大抵70度に到達するのですが、このGPUは70度到達しないのでこれはよく冷えるなーって。 すごいですね。
それにしてもLinuxのやつでASUSのグラボのカラーコントロールとかできるんですかねぇ? できるならせっかくだしきれいにしてもいいかもしれない。 私はオタクなので真っ青にしますけどね。
あまったパーツでマシン組んだ
PC組みたい3年生が組んでくれました。 組みにくいケースを渡しちゃってよくなかったなーって反省しています。 GPU以外はおまけのようなパーツ構成ですがちゃんと動く。
この子はkubernetesの6代目のワーカーノードになる予定です。
田胡研のk8sは私が勝手に増殖させたせいでかなりの化物スペックになりつつあります。 ここでもうひと頑張りして卒業までに成果を出したいところです。
どうでもいいはなし
PCパーツといっしょになんかでっかい曲面ディスプレイも届きました。 まぁ安物なんですけど。 ここ最近の研究室は仮想通貨の研究室になりつつあるのでチャートとか大量に表示してなんかかっこいい感じにしたい。 明日にでも適当なディスプレイを掻っ攫ってチャートを表示して遊ぼうと思います。
10GbpsのL2スイッチが発注済みなのでそのうち届くのですがこれの配線を考えたりしていました。 今日だいぶ配線を調べて配線図に起こしたのでいいかんじの配線をしたいです。 調べていてわかったのは闇が深いということです。 NASのセットアップ(ファイルサーバの移行)も早めにやっておかないとなので忙しいはずなんだけどずっと遊んでるしよくない。
ボードゲームチャンネルとか仮想通貨チャンネルとかブログチャンネルとかSlackに追加されるし最近研究室が活発感を感じて楽しいです。 さっさと適当に卒論を書いて楽しく遊びたいです。
サーバの写真とかしか撮っていないんですけど、スマホカメラがゴミで嫌だなーって感じました。 ご立派なカメラを買う気は一切ないんですけど、なんかもうすこしちゃんとした写真がさくっと撮りたいです。
Java9の新機能をちょろっと触ってみた
はじめに
この記事は、私の所属する田胡研究室のアドベントカレンダー9日目の記事です。
Java9
Java9が9月にリリースされてから早3ヶ月。 私はJava7のコードを某所で今も書かされています。
StreamApiがないJavaとかマジやってらんね。 for文でリストの写像とかしなきゃいけないんですよ。 マジだるい。
さっさとJava9に置き換えろこの野郎という怒りをぶつけながらこの記事を書こうと思います。
Java9で変わった大きな変更と、使えそうな典型をちょろっとしたコード共に紹介します。
JEP
Java9の新機能はJEPとして提案されOpenJDK開発コミュが対応しました。
http://openjdk.java.net/projects/jdk9/
ここにまとまってます。 この中でも私みたいなへなちょこJavaプログラマーに効きそうな機能はこんなところかな?
イケイケなJava9の機能
- moduleシステム導入
- jshellとかいうREPLツール導入
- StreamAPI強化!!
まぁほかにもJVMのロギングの対応とか、Unicode8とか、Http2とか、乱数ジェネの強化とか、SHA3とか、非推奨GCが出たり、ファイナライザ変更とか、LocalDateTime強化とか、AOTコンパイラツールとかいっぱいあるんで、好きな人はJEP読んで。
Moduleシステム
Javaに新しい構文が追加された。 拡張子が.javaなだけのJavaじゃないコード誕生。
これまでJava類似機能をパッケージ
という単位でまとめ、それらを圧縮ファイルにしてライブラリ(JAR)
として提供していました。
適当なjarファイルを落としてきて使うっていう便利な機能ですね。
これは便利なんですが課題がありました。
- 可視性の設定が十分でなく、ライブラリ内部の機能を公開してしまう
- ライブラリの依存性の定義がないため、不足ライブラリがあったら探し出して落とさなきゃいけない
こんなところ。
jarを適当に落としてきて使ったら、依存関係ですぐに使えず、結局10個くらいjarを探し出して入れたことがある人は少なくないと思います。 某所でもこの前教授が依存関係で嵌ってぬわーんってしていました。
これらがモジュールシステムで対処可能になりました。 新しいディレクティブが追加されまくって公開とか依存関係とかを定義できるようになっています。
すごいですねModule。
module jp.ac.teu.cloud.service { }
こんな記法からmoduleの設定ができますよ。 どっかで今後この記法見ても???ってならないように気をつけないといけませんね。 ちゃんとした使い方はいろいろなところでそっちを参考に。。。
jshell
これ私みたいなへっぽこJavaプログラマーには良い機能では? javaのインタプリタみたいなやつ よくrubyとかpythonとかでやれるやつ。 弊研生はJavaのインタプリタつくりましたーーー!ってこのコードを全部提出して単位を貰うと良いよ。
こんなもんです。
Javaは雰囲気でどんな値返ってくるかとかわかるから、試しにライブラリの関数呼んでみるみたいなことは、需要がそんなあるわけじゃない気がするんだけど。。。 やろうとしたとき一々クラスファイル書かなくてよくなったのは便利!!
講義とかでちょろっと見せるのに使えるかも知れませんね。 まぁ弊学では、皆にJavaを教えたはずなのに、課題でラムダ書いたら大半が理解できなくて、おまけに老害みたいなこと言い始めたSA・TAまでいたのであれでしょうけど。。。。
StreamAPI強化
あいつがもっと強くなった。 streamapiというとこいつとか。
List.of(1,2,3,4).forEach(System.out::println)
サンプルがこれかって? 便利じゃないですか。
あList.of()
っていうのはJava9で追加された子です。 ついにこいつができた!。 今までよくstatic final
なリストやマップに、staticイニシャライザで値を突っ込んで、よく分かってない人からなんですかこの構文?って聞かれたことがある人は多いはず。
private static final List<String> hogeMap = new ArrayList<>(); static { hogeMap.add("にゃーん"); }
こんな無駄なことをしなくてもいい。
List<Integer> lst = new ArrayList<>() { public ArrayList() { super(); add(1); add(2); add(3); add(4); return; } }
こういうのとかもしなくていい。 あ、上のコード、Java8だとArrayListのあとのジェネリクス省略でコンパイル通らねーぞ^_^と思った人。 Java9だと匿名クラスのジェネリクスを上手い感じにしてくれるのでいけます。
of
メソッド 便利なんですが注意点が一つ、以前Arrayからのofでリストつくるとかしてた人なら分かると思うけど、できあがるのは不変リストなので、変えたい場合はこれでできた値を新しいリストのインスタンスにつっこんで使いましょう。
StreamAPI自体としては、streamインターフェースにいくつか便利なのが追加されました。 takeWhile(Predicate<? super T>)
とかです。 意外と便利?
個人的にはCollecters
の拡張がありがたいです。filterling
とか。 終端でフィルタを噛ませられるようになったよ。
さいご
Javaは8からの進化がいいですね。 私は進化とレガシーさの良い感じのバランスが好きです。 でも某所のJava7は無理。 マジで無理。 イケイケなひとが全部Java9にしておいてくれないかなーって。 まぁ某所がJava7のままなのは私が手を付けなかったせいでもあるので、あまり文句は言えないんですけどね。
StreamAPIの新規追加メソッドの全サンプルとか載せたかったけどちょっと日和ってしまいました、ごめんなさい。
Javaをメインで書くことは今後減るんだろうけどずっと追い続けていきたいなーって記事書いてて思いました。
明日の田胡研アドベントカレンダーは期待の3年生のfubukiくんです。 ご期待下さい。
javascriptとYAML
今日したこと
某所のフロントでyamlを使ってとあるオブジェクトを構築したりしているのですが、ちょっと高度なyamlの機能を使いたくなった。
まだやったことがなかったyamlの機能をjsで使ったら想像以上に使えて感動したので今日はその知見でも。
yamlのアンカー
yamlは参照が使えますね。 この点でyamlは木構造以外のデータ構造をシンプルに表現できるので強いです。
sample.yaml
pan: &item1 name: item1 price: 100 pon: *item1 pen: *item1
こんな感じでアンカーをつけて参照すると pen,pon,penそれぞれが同じnameとpriceを参照するようになります。
jsonとかだとこれができなくて色々と辛いことがあるけどyamlはできる!! すごい!!
javascriptでyaml
これを使うことでyamlからパース&yamlにシリアライズが可能です。
Load
がパース,Dump
がシリアライズです。
yaml = require('js-yaml') fs = require('fs') try { var doc = yaml.safeLoad(fs.readFileSync('sample.yaml')) console.log(doc) doc.pon.price = 200 console.log(doc) var dump = yaml.safeDump(doc) console.log(dump) } catch(e) { console.log(e) }
前述のyamlをパースして 参照先のpriceを更新、オブジェクトをシリアライズします。
実行する
{ pan: { name: 'item1', price: 100 }, pon: { name: 'item1', price: 100 }, pen: { name: 'item1', price: 100 } } { pan: { name: 'item1', price: 200 }, pon: { name: 'item1', price: 200 }, pen: { name: 'item1', price: 200 } } pan: &ref_0 name: item1 price: 200 pon: *ref_0 pen: *ref_0
参照になってるからpriceが全部同じところ参照してて更新すると全部変わる! シリアライズもちゃんと参照を維持してくれる。
公式のデモ
どんなことできるか一覧のデモです。 yamlの機能(知ってる限りは)全部使える感じ。 ファンクションとかも行ける すごい。
in webpack
この辺を使うのがいいでしょう。
ただ yamlfile
=> yaml-loader
=> json-loader
というつながりで読み込むやつなのでyamlがJSON相当のものしか扱えないのが残念です。webpackでyamlの高機能使いたいときはtextで入れて置いて実行時パースかな?
javascript object marshal?
yaml強いのでそこそこに使えそう。 ただJSON.stringifyのが速いわけだからパフォーマンス的には当然難しい。 頻度が低いなら問題なくいい感じに使えるかも。