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のが速いわけだからパフォーマンス的には当然難しい。 頻度が低いなら問題なくいい感じに使えるかも。
Linuxでログインを検出して通知するちょっとしたコード
きょうしたこと
サーバでログインしたらなんかSlackに通知とか来るようにしてこの共用鯖どれくらい使われてるのかなーとか測ろうと思いました。 適当なコピーすれば動くサンプルあるだろーとおもったらすぐには見つからなかった。 なのでシェルスクリプト書けない無能なりにちょっと頑張って書いた。
Linuxのログイン履歴
ログイン履歴は last
コマンドで見れます lastlog
コマンドを使うともう少しちゃんと出ます.
新しくログインをするとlast
コマンドの出力結果に時間とかユーザ名とかIPが出てくるのでこれを使えばログイン検出できそうです。
ログイン検出してなんか走らせる汎用コード
last
コマンドをちょろっとつかって作った結果
#!/bin/bash set -eu last | sed -n 1p | awk '{print $1,$4,$5,$6,$7}'> login.log while : do # loginログ最新を漁る last | sed -n 1p | awk '{print $1,$4,$5,$6,$7}' > latest.log if diff -q login.log latest.log >/dev/null ; then # 新規ログインがない : else # 新規ログインがある echo "`hostname`で新しいログイン `cat latest.log`" # ここから通知とかのスクリプト叩く mv latest.log login.log fi sleep 10 done
こんな感じで行けました。 シェルスクリプト力の無さがコメントとかににじみ出ていますね。 一応これでログインが行われるとコンソールに出力されます。
そういえば初めてawk
とか使った。 知見が増えました。 色々便利な使い方をこれから知っていきたいです。
このコードを使えばあとは
こういう先人の知恵を参考にさせていただいてスクリプトからSlackに飛ばせばOKです。
どうでもいい話
某所のサービスでNginxの設定変更が必要で色々とやってました。 実際にはk8sのNginxIngressControllerなんですが。
設定を変更してもなんかうまく動かなくてなんでー???って机バンバンしたり研究室の中をぐるぐる回ったりしていました。
結局
Nginxの変更適用されなくて????ってしてたら問題引き起こしてるのはその上の段のNginxだったOTZ。。。
— namazu (@namazu510) 2017年12月6日
こういうアホみたいな原因でした。 ちゃんと上段も設定したらうまく行きました。 全体を把握してから取り掛からないと時間がかかることがあるよっていういい知見を得ました。
田胡研とジェンガとXXX
はじめに
この記事は、私の所属する研究室、田胡研究室のアドベントカレンダー5日目の記事です。
登録したときからしょうもないことを書くと宣言していたとおり、今日はネタ記事を書こうと思います。
今日は田胡研でみんなでよく遊んでいるジェンガについての記事を書きます。
田胡研ジェンガルール
普通のルール
箱に書いてあるジェンガの一般ルールは以下の通りです。
- サイコロを振る
- サイコロの出目に指定された色のブロックを山から抜きます。 もし★の出目であれば2ブロックを抜く。
- ブロックを上に積む、ブロックは一番面積の広い面を接地させるように置かなければならない、また1段に3つブロックが置かれ埋まるまで次の段においてはいけない
山を途中で崩した人が負け。
これが普通のジェンガのルールです。
田胡研ルール
田胡研では変則ルールが適用されており、
- ブロックを積む際はどの面を接地させてもよい。 => つまり縦に積んだりしてもよい
- 縦に積むなど変な積み方が始まった場合、それ以後はその積まれた位置より上に置かなければいけない。
というルールが適用されています。 つまり。。。
こんなことになります。 >_<;
変な積み方をしてもいいというルールなので、普通に置くこともできます。 しかし、なぜか頭のおかしい人が縦に積み始め「勝負に出る。」とか「ここで潰す。」とか言い出しておかしなことになります。
これまでまともなジェンガは2,3回しかやっていません。
負けるとこうなる
ちなみに弊研では×ゲームと言えばデスソースと化しており、デスソースの一番辛いやつ10g入のカップ麺をすでに三回ほど食べています
— ううたろ (@uutarou10) 2017年12月4日
某所で既にどうなるか公開されていましたが、煽るのが大好きな頭のおかしい人のせいでデスソースをかけてカップ麺を食べるなんていうのが日常になっています。 こんな感じ。
デスソースが届く前はそこそこ辛いカップ麺を食べるくらいだったのですが、、、デスソースが来てからいっきにきつくなって来た。 今ではほんと負けたくない。。。 誰だデスソース買ったやつ???
辛いのを食べて苦しんで暴れているところ、を誰かが「喜んでる。」なんて煽りだしたりして、最近はお先真っ暗感のある戦いになってる。 そのうちみんなデスソースで死ぬ。
田胡研ジェンガ攻略
負けたくないのでちょっと攻略法を考えました。
ジェンガの重さ
知らない人がたまにいるのですが、ジェンガの重さはそれぞれ違います。 全部均等だと重さがうまく偏らなくてつまらないゲームになってしまうので、そうならないようにある程度バラしてあるそうです。 実際の重さの変化幅とどれくらい分布しているのか調べました。
測定方法
このような感じに重さをそれぞれ測ります。 研究室にはしょぼい秤しかなかったので、1g単位ですが。。。
全部測って重さ順に並べるとこんな感じ
左側が14g 右が21gです。 最大で7gの質量差があることがわかります。
数値分布を詳細にグラフにすると
こんな感じになります。 秤が1g単位でしか測れないので変な感じのグラフになっていますが、どうやらジェンガは18gぐらいが一番多く存在しそこから離れるほど数が少なくなるようです。 もっと大量に制度測れば分布関数とか出せそう。
どうすべきか。
ジェンガの重さに差があるため、高さがやばくなってきたら、軽いジェンガを上においてお茶を濁すとか、初めのうちは重いジェンガを置いて安定させるとかすると長くジェンガが続きそうです。
ジェンガの台
田胡研ジェンガいつからあるのかわからない不安定な台の上
でやることになっています。 この台、なんか手を触れると揺れます>_<。 よく揺れることはみんな知っているのですが、この台、明らかに傾いています。
どれだけ傾いているか測りました。 その結果。 上の写真の奥から手前側の間45cmで0.6cmくらい下がっています。 つまり、0.6度位傾いていることがわかりました。
どうすべきか。
まぁどれだけ傾いているかわかったところであまり参考になりませんが、7段目から先を積むときに重心を見抜く1つのポイントにはなるでしょう。
戦略とか
ジェンガは積極的に他人に倒させていきましょう。 田胡研ジェンガにおいて抜くのは比較的容易なので、詰みにくさから誰を潰すか狙うことが出来ます。 サイコロを降るときに机から落としてしまうと確定で2個を積むことになるというルールがあるので、5個積まれた状態で、わざとサイコロを落とし2つブロックを積むと隣の人は8段目を積むことになるので大抵殺せます。
段を置く毎にどんどん難しくなっていくのですが、大体無事に積める確率は
- 1〜5 段目 98%置ける
- 6段目 90%置ける
- 7段目 65%置ける
- 8段目 30%置ける
- 9段目 10%置ける
- 10段超え 未知の領域
こんなかんじなので参考にするといいでしょう。
あと倒したらデスソースなのでそのプレッシャーを与えると手がみんな震えます。 煽っていきましょう。
攻略法はこんなところ。 みんなで憎きアイツにデスソースカップ麺を喰わせよう!!
そういえばデスソースは使いきったんだけどさ....
罰ゲームでデスソース使いまくってたら、使いきって。
即座に、
>_<;
さいご
弊研では昔、縦に11段まではジェンガが積まれたことがあるそうです。 なので
tg研アドベントカレンダーではジェンガ11段積み上げて写真をあげたい
— namazu (@namazu510) 2017年12月3日
これをしたかったのですが、30分くらい一人でやっていても9段が限度でした。 ジェンガしてると無限に時間がなくなってタスク終わらないので気をつけましょう。
アドベントカレンダー明日は、3年のsekunがイケイケな記事を書いてくれるそうです。 多分明日は技術ネタです。 素晴らしい記事が来ることでしょう。 それでは。