本を読む

読書やコンピュータなどに関するメモ

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

ポメラDM200にDM100から乗り換えた

キングジム デジタルメモ ポメラ ブラック DM200
キングジム
売り上げランキング: 3,474

 テキスト入力専用マシン「ポメラ」を、DM100から、2016年に発売された最新機種「DM200」に乗り換えました。

 DM200が発売された当初は「Wi-Fi対応」がクローズアップされて、「Wi-Fiいらないし、それで5万円超えるんじゃ、DM100でいいや」と思っていました。しかしその後、インタビュー等で、日本語変換を組み込みATOKからより高性能なものに替えるために、OSから作り直したという話が公開されるようになりました。DM100の日本語変換には少し不満がありましたし、仕事が効率化されるならお金を払ってもいいかなと思い、DM200を買うことにしました。

 以下に、ざっとDM200の感想をまとめておきます。私としては満足しています。なお大前提として、(主に出先で)まとまったテキストを入力するのが仕事とか重要な趣味とかいう人以外にはお勧めしない、特化型デバイスです。

良かった点

  • 日本語変換:DM100では思ったとおりに変換できなくてストレスを感じましたが、DM200なって改善されました。ただし、予測変換とかには対応していません。
  • 文字コードと改行コードが変更可能に:いままではShift-JISとCRLF改行固定でしたが、DM200ではUTF-8やLF改行に設定で変更できるようになりました。ただしBOMつきUTF-8です。
  • ひっくり返らなくなった:DM100ではキーボード側が軽くてディスプレイ側が重いため、大きく開くとひっくり返りそうになることがありました。DM200ではキーボード側にバッテリーが入っっているそうで、ひっくり返りにくくなりました。
  • USB端子がminiUSBからmicroUSBに:ポメラ専用にminiUSB端子のUSBケーブルを持ち歩く必要がなりました。

ややネガティブな点(慣れればいい程度)

  • USB接続でPCからマウントするときに操作が必要に:DM100ではつなげばマウントされましたが、DM200ではメニューから「PCリンク」を指定するようになりました。まあ、慣れです。
  • 蓋を開けて電源が入るまで3秒ぐらいかかる:とりあえず今のところそれほど困っていません。

その他

  • 乾電池からUSB充電式に:予備電池に入れかえることはできませんが、汎用のUSB充電器が使えて、しかも動作中にも使えるようになって、プラスマイナス(ややプラス)という感想です。
  • オートセーブ機能:事前にオートセーブ機能が付いたということで期待していました。一定時間ごとにセーブする機能を期待していましたが、そうではなく、ファイルを開くときやPCとつなぐときにセーブする機能でした。
スポンサーサイト

Atermの簡易NASとUbuntuのufw

 NECのWi-Fiルーター「Aterm」シリーズでは、USBメモリを挿せば簡易NASとして使える機能があります。これを自宅内で、マシン間のファイル交換用に使っています。NAS製品も設置していますが、24時間運用はしていないので。

 これをいままで、ノートPCにインストールしたUbuntuからも使っていました。「ルーターの簡易NASを共有できなくなった」みたいな対策は必要でしたが。

 このUbuntu 16.04をUbuntu 16.10にバージョンアップしたころから、Atermの簡易NASにアクセスできなくなりました。挙動を見ると、Windowsネットワーク名が引けなくなっているような感じでした。

 Nautilusやsmbclientでいろいろ試して、Ubuntuのufw(ファイアウォール)をオフにするとアクセスに成功しました。そこで再びオンにして試したところ、ログ(dmesg)に、UDPの5355番ポートをブロックしたと記録されることが確認できました。LLMNRってやつですね。

 Ubuntuのバージョンアップによるものか、それとも前はufwがオフになっていたか、正しい原因は不明です。ufwでLLMNRを許可することも考えましたが、外(公衆無線LANなど)でSMB系のアクセスを許可する必要もないので、家ではufwをオフにして外ではオンにすることにします。

Clojureでひらけ!ポンキッキ(文字列の回転)

 無限リストといえばClojureということで、Clojureのリハビリとして真似してみます。

(defn rot [s]
  (let [l (count s)]
    (dotimes [i l]
      (->> s cycle (drop i) (take l) (apply str) println) )))

 なんというか、まんまですね。

user=> (rot "ひらけ!ポンキッキ")
ひらけ!ポンキッキ
らけ!ポンキッキひ
け!ポンキッキひら
!ポンキッキひらけ
ポンキッキひらけ!
ンキッキひらけ!ポ
キッキひらけ!ポン
ッキひらけ!ポンキ
キひらけ!ポンキッ
nil

GNU grepで-oと-cの組み合わせに失敗

 GNU grep依存でよければ-o(マッチした部分を抜き出す)と-c(カウント)で行けるかと思ったら、うまくいかなかった。

$ sep=x
$ echo xabcxghi | grep -ocFe "$sep"
1

 GNU grepのmanを見ると、-cはマッチした行数をカウントするようだ。

-c, --count
       Suppress  normal output; instead print a count of matching lines
       for each input file.  With the -v,  --invert-match  option  (see
       below), count non-matching lines.

 というわけで-cをやめてwcに。

$ echo xabcxghi | grep -oFe "$sep" | wc -l
2

Red Hat Forum 2016「パネルディスカッション 来たるコンテナ時代に向けて」

 レッドハットのイベント「Red Hat Forum 2016」で、Publickeyの新野さんをモデレーターにしてパネリストに前佛さんなどが並んだ、コンテナ/Dockerをテーマにしたパネルディスカッションがありました。

 だいたいメモったので、ほぼそのままブログに残しておきます。

メンバー

  • Publickey 新野淳一氏

パネリスト:

  • Ian Lewis氏 グーグル株式会社 Google Cloud Platform Developer
  • 小俣裕一氏 株式会社ディー・エヌ・エー SWET Gr, Quality Management Dept, System Management Unit Software Engineer in Test
  • 前佛雅人氏 さくらインターネット株式会社 技術本部ミドルウェアグループ
  • 木村貴由氏 レッドハット株式会社 カスタマーエクスペリエンス&エンゲージメント アプリケーションプラットフォームサポート シニアソフトウェアメンテナンスエンジニア

自己紹介

  • 新野:コンテナにどんなメリットがあるか
  • それを引き出すのにどんなプラットフォーム?
  • などついて話しあう
  • まず自己紹介
  • Ian:Google Cloud PlatformのDeveloper Relation
  • 開発者の支援、コミュニティの支援、OSS開発を中心に
  • 小俣:10月から部署名がかわった
  • SWET(Software Engineering Test)
  • クラウドのユーザー側として
  • 前佛:テクノロジーエバンジェリスト
  • 弊社の技術を紹介する
  • コンテナは前職つながり。Dockerのトレーナー
  • 趣味でDokerのドキュメント翻訳
  • 木村:RHでOpenShiftのサポート
  • もうかなり多くのお客様が使っている(アメリカ)
  • 調査の手伝いなど

コンテナのメリットは

  • 新野:コンテナとは何か。木村さん
  • 仮想化とどう違うか
  • 木村:仮想化とよく対比されるが
  • 共通する点としては
  • どちらも隔離されたランタイムを提供
  • 大きく違うのは
  • コンテナはLinuxのOSの機能で隔離。なのでLinuxのみ
  • 仮想化はほかのOSも
  • 新野:いちばん違うのはハイパーバイザーの有無?
  • 木村:ハイパーバイザーとゲストOS
  • 制限はあるが
  • リソース効率がよい、起動停止が速い、軽量
  • ストレスを感じなくなるレベルで軽量
  • 普及したのにもう一つ理由
  • Dockerの登場
  • イメージフォーマットとイメージ共有基盤
  • セットアップ済みのコンテナイメージが利用できる
  • →インストールという概念がなくなる
  • Ian:JenkinsがJavaで作られている。実行にJavaランタイムが必要
  • DockerのJenkinsイメージならランタイムが入っている
  • 新野:利点2つ。軽量、イメージ
  • 前佛さん、本当ですか?
  • 前佛:本当ですw
  • 仮想サーバーを立ち上げる必要がない
  • 新野:小俣さん。実際に使ってますか?
  • 何がいいか
  • 小俣:テスト。サーバーサイド。
  • 開発者視点では、開発ツールチェーンを入れる必要がない
  • RailsではRuby、Rails、ライブラリ、DB…
  • テストは多くのターゲット
  • MySQLだったりPostgreSQLだったり
  • OSのバリエーションも
  • いちいちインストールするのは大変
  • DBのインストールの学習コストもかかる
  • 新野:テスト用のデータはDockerで?
  • 小俣:データは入っていない
  • 外からロード
  • 新野:ほかのメリット
  • 小俣:スマートフォンのテストファーム
  • 実機を数十台、リモートで
  • バックエンドOSの違いなど
  • Dockerを使わなくても設定は自動化するが
  • その準備で5〜10倍のコスト削減
  • 新野:ここまで、Dockerイメージがポータブルという話
  • 軽量という点は?
  • 小俣:私はフロントのサービスで使っていないので、それほど軽量であるメリットを感じていない
  • 木村:軽量化のメリットは、待たなくていいことと、数の積み上げ
  • 1000台となると、オーバーヘッドが積み上がる
  • 新野:密度もいわれる
  • 木村:集約率は1.x倍ぐらい上がる

コンテナで困ること

  • 新野:木村さんは話がうますぎる気がするw
  • コンテナで困っているお客さんの話は?
  • 木村:ある
  • コンテナに持っていくときに
  • カーネルに特定のパラメータを設定するもの
  • 商用ソフトはインストールの要件が決まっていたり
  • 新野:小俣さんは困ったこと
  • 小俣:違う使いかたで
  • ゲームのプラットフォームでコンテナを使うか議論したことがある
  • 不利ということになった
  • 新野:その話を続けて
  • 本番で使うかどうか
  • DeNAで本番で使っていない背景
  • 小俣:オンプレミスのサーバーを4千台(2千台×2重)
  • AWSのサーバーも
  • 2種類対応
  • 新しいプラットフォームをもちこむ学習コスト、調査コスト、運用コストの不安
  • VMとは分離方式が違う。自信が持てない
  • もう1つの理由
  • コンテナを使ってもVMを使っても、運用に人員が必要
  • 監視にも人が必要
  • データストア、ログ、セキュリティスキャンなど
  • 新規人材が不足。新しい学習コストはかけられない
  • GAEではそこから解放される
  • 新野:Ianさん、どう思うか
  • Ian:コンテナー化には学習コスト、コンテナ化コスト、デプロイを考えるのが必要
  • スケールも楽になるプラットフォームがいいんじゃないかということだと思う
  • 実際には、その間のようなサービスがいいんじゃないか
  • 新野:コンテナでGAEみたいに使えるもの
  • 前佛さん。運用コストが変わらないというのは
  • 前佛:はい、そうです
  • 個人的な意見
  • Dockerの学習コスト
  • 開発が速い
  • 日々バージョンアップ
  • 3か月に一度、仕様が変わる
  • 木村:最近でいうと
  • Docker 1.1で下回りがかわった
  • Docker 1.12でオーケストレーションが入った
  • 前佛:そういうのを追いながらになる
  • 新野:どこから情報
  • 前佛:じつは最近はまっている
  • 昔はDockerのブログで追えた
  • 最近は技術的なことが載らなくなった
  • DockerのSlideShareに技術系資料
  • Docker captainという制度がはじまった
  • ユーザーが情報を出す制度
  • そのへんはDockerのTwitterアカウントで

さくらのサービス「Arkas」

  • 新野:次の話題
  • 中間的なコンテナプラットフォームの話
  • ベンダーさんの声。前佛さん、Arkasについて
  • 前佛:Arkasというコンテナサービス
  • 何でもできるものではない
  • いまβサービス
  • やりたいことはサーバーフロントエンドのコンテナを簡単にデプロイ
  • 本番環境にはサーバーやネットワークを用意しなくちゃならない
  • コンテナを実行してスケールできる
  • 新野:フロントエンドというのはWebサーバー向け?
  • 前佛:いまのところは
  • 新野:そこを選んだ理由
  • 前佛:コンテナのメリットのある部分
  • インフラの部分は生臭い。冗長性、可用性
  • Arkuasはさくらのクラウド + CoreOS、オーケストレータ/スケジューラ
  • 可用性を求めると現場は大変だろうなと

オーケストレータ/スケジューラとは

  • 新野:オーケストレータ/スケジューラとは?
  • Mesos、Marathon、Zookeeper、何?
  • 前佛:よしなに処理してくれる
  • Mesos。コンテナだけではなく、10台のサーバーにジョブを投げてよしなに実行してくれるツール
  • その上でジョブを動かすMarathon
  • 冗長性のためにZookeeper
  • オーケストレータ/スケジューラというのは各社定義が違う
  • 私の定義は
  • あるべき状態を維持してくれるもの
  • 新野:落ちても再起動してくれる?
  • 前佛:はい
  • 新野:木村さんの定義は違う?
  • 木村:オーケストラには指揮者
  • その指揮者がオーケストレータ
  • 新野:Ianさん
  • Ian:「管理」に近い意味
  • ノードを追加、コンテナを削除など、いろいろあった
  • オーケストレータがおまかせで、あるべき状態に
  • 新野:前佛さんに戻して
  • いままでアプリを手で起動していた
  • コンテナだと200個立ち上げる
  • その自動化レイヤー?
  • 前佛:近いと思います
  • 新野:なぜArkasではCoreOSやMesosを選んだか
  • 前佛:その当時あった技術で、使いやすそうだったから
  • Mesosはコンテナ専用ではなく、複数のサーバーで分散処理するもの
  • コンテナに対応したので
  • 2年前
  • 新野:今だったら違う判断?
  • 前佛:はい
  • そのときどきの技術
  • とはいえ、裏側は知らなくても使っていただけるサービスにしたい

Googleのコンテナ利用

  • 新野:Googleではすべてコンテナ
  • Ian:本番でコンテナを使っている
  • 10年ぐらい
  • オーケストレーションのシステムも社内で作った
  • 新野:Dockerは何年前ぐらい
  • 木村:3年ぐらい
  • Ian:コンテナの技術が、Linuxカーネルに入った
  • 知っている人は使えた
  • 使いやすくはなかった
  • コンテナという機能ではなく、いろいろな機能の組合せで実現
  • cgroup、namespace…
  • Dockerが出て、つかいやすいものが出た
  • Googleは自分たちでかなり前から
  • オーケストレーションをどうするか、社内で考えた
  • 自分たち用のシステムを作った
  • ベストプラクティスがない時代から
  • やり直したい部分、Dockerを使うとどうなるか、と考えて、経験をもとにほかの人が使えるシステムとして、Kubernetesを作った
  • Kubernetesはコンテナのオーケストレーション
  • 複数クラウド対応のロードバランサーなども
  •  他社のクラウドもGoogleにも、オンプレミスでも
  • オープンソースなのでどこでも
  • コンテナオーケストレーション図解
  • Webアプリをデプロイするとき
  • それをAPIで伝える
  • Kubernetesが自分の持っているリソースのうち空いているところにデプロイしてくれる
  • デプロイした後に、リソースを食っているとき、リソースを分散してくれる
  • 新野:KubernetesをもとにGoogle Container Engineも動いている?
  • Ian:Kubernetesで簡単に立ち上げるプラットフォーム
  • APIか画面からKubernetesのクラスタを作れる

Red Hatのコンテナプラットフォーム

  • 新野:RHのコンテナプラットフォーム
  • 木村:Linuxカーネルの機能をサポート
  • 「本番環境では不安がぬぐえない」正しい
  • Dockerはセキュリティリスクがある
  • それを解消するためにRHが製品化
  • 周辺ツールが圧倒的に足りない
  • 運用のためのプラットフォーム
  • 穴をうめてあげる
  • 足りないところ
  • Kubernetesで
  • オーケストレーションとスケジューリングはできる
  • UIは使いやすくない
  • ネットワークもプラグイン機能まで
  • レジストリ
  • イメージのビルド
  • そこにいっぱい機能を追加したのがOpenShift
  • 新野:OpenShiftはソフトウェア? サービス?
  • 木村:OSS。
  • サービスもあるが、想定ユーザーはちょっと違い、社内にコンテナプラットフォームを持ちたいというお客様
  • コンテナの特性が役立つのは開発。が、それをパブリッククラウドでやると課金が大きい
  • 基本的には製品として提供

現状

  • 新野:小俣さん。ユーザーとしてどう聞いたか
  • 小俣:GUIがあるのかと。勉強不足だった
  • 新野:欲しい方向に進化している?
  • 小俣:していると思う
  • 新野:それを受けてIanさんと前佛さんに
  • Ianさん、GAEとコンテナ。そういう方向に?
  • Ian:できるだけラフに使えるように
  • GAEもあるが、GKEも進化させる
  • 新野:OpenShiftとKubernetesは同じようなコンポーネント
  • Arkuasは違う構成だが、目指すところは同じ?
  • 前佛:どうだろう
  • ノリではじめたところがあってw
  • とりあえずコンテナを動かしたいこと
  • Kubernetesはサポートがついた?
  • 木村:メジャーバージョンが出てから7年
  • 前佛:いまの機能は、とりあえず動かすなら充分
  • 長期に使うには、そちらでいいんじゃないですかw
  • 新野:共通していること。周辺が充実して手間なく使えるように
  • 木村:ツールやノウハウが浸透していない
  • OpenShiftはとりあえずえず機能はそろった
  • まだ埋められる役割はあるが

従来型のアプリもコンテナに?

  • 新野:既存のRHELは金融などレガシーなアプリも動いている
  • それらもコンテナに乗っていく?
  • 木村:はい
  • 実際にサポートしているのは、銀行やキャリアなどが多い
  • 絶対に落とせないシステム
  • いまのトレンドは落ちても障害にならないように作る
  • リカバリ、影響範囲コントロール
  • マイクロサービス
  • それとコンテナが相性がいい
  • 新野:その場合、既存のサービスそのままではなく、作りかえる?
  • 木村:モノリシックなアプリを、複雑でなければ、不可能ではない
  • が、業務アプリは複雑。コンテナ化が難しい
  • ポータブルなコンテナにするには設定をコンテナの外に
  • 旧来のアプリはそんな機構ないので改修が必要
  • 新野:前佛さん、Dockerに詳しい人として
  • 既存アプリをDockerにのせてうれしい?
  • 前佛:うれしい場合はある
  • 開発
  • テストが速い、高速なデプロイ
  • 運用は死ぬw
  • 密度が上がる部分
  • 仮想化のときといっしょ。仮想化は監視ツールが整った
  • つめこみすぎると、いったん障害が起きると被害が大きい
  • 監視が必要
  • コンテナのメリットをいかすには運用フローがかわる
  • 物理・仮想化・クラウドは運用が同じだった
  • コンテナでは変わる
  • 監視ポイントも変わる
  • Ian:まさにそのとおりだと思う
  • 仮想マシンで管理していた人が、コンテナになると、VMもコンテナも管理
  • それが監視が大変
  • 前佛:だからKubernetesやOpenShiftが便利ということですねw
  • 新野:それって本当にそういう方向に進化している?
  • 前佛:そうでないと回らなくなる
  • 新野:そういう危機意識がある人がコントリビュートすると
  • 前佛:貢献もそうだが
  • まずは使ってみること
  • 頭で考えてもわからない
  • 何がいいか悪いか、自分の言葉で説明できるように

今後は?

  • 新野:最後に、今後、どう変わっていくか、変わってほしいか
  • Ian:2つ
  • 1つは、コンテナは、RHやGoogleが基礎的な部分を必死で作ってきた時代だった
  • たとえると、Linuxを使えるようにすること
  • その上にディストリビューションができた
  • その上にいろいろなアプリケーション、エコシステム
  • いまのコンテナは基礎の部分ができつつ、若干ディストリビューションができつつあるところ
  • それがどんどん進化していくと思う
  • あとは、低レイヤー
  • これまでDocker。コンテナの標準化がこれから
  • Open Container。
  • イメージフォーマット、実行方法などを定義
  • これから
  • 小俣:まだ足りない部分があると思っていた
  • RHがいうように進化してきている
  • 開発したオープンソースの最新版を開発者がコンテナで提供するようになると助かる
  • あと、個人的に
  • 子供の教育をRaspberry Piなどの小さいデバイスで、RubyやNode
  • 開発用のツールチェーンのインストールや差異がトラブルになる
  • それをDockerで
  • 前佛:個人的な期待としては
  • コンテナで開発や運用が、本来したかった方向になるかなと
  • これまで80年代の手法をひきずってきた
  • コンテナの軽さで、業務フローまで変えられるのではないか
  • 木村:3点
  • 1。いまマイクロサービスにシフト
  • 影響範囲を限定して開発
  • これにコンテナがマッチ
  • 2。環境構築の容易性
  • Jenkins、MySQL、アプリケーションサーバー
  • イメージ化されて
  • 新しい開発者にもすぐ環境を手渡せる
  • 開発が高速化されることが期待
  • 3. DevOpsを手助けするツール
  • 開発したものをそのままテスト環境や本番環境に
  • それをプラットフォームが吸収してくれる
  • 開発のサイクルを速く
  • 新野:リアリティのある話を聞けた
  • みなさんの参考になるのではないかと思う

bash 4.4の新機能リストを訳してみた

 bash 4.4がリリースされたので、NEWSファイル(新機能リスト)からbash 4.4の新機能の部分を訳してみました。

Bash on Ubuntu on WindowsでPandocを動かすには

 Windows 10のAnniversary Updateで、Windowsカーネルに皮をかぶせてLinuxユーザーランドを動かすWindows Subsystem for Linux(WSL)と、WSLを使ったUbuntu環境のBash on Ubuntu on Windowsが入りました(β版)。

 Ubuntuのパッケージがそのままインストールするということで、汎用ドキュメント変換ツールのPandocをインストールしてみました。

$ sudo apt-get install pandoc

 カーネル的には入出力ぐらいで、そんな難しいシステムコールは使ってないだろうと思ったら、システムコールが足りないとエラーに。

$ pandoc foo.md -t html -o foo.html
pandoc: timer_create: Function not implemented

 検索してみると、この件は公式でもissueが立ってました(timer_create not implemented! · Issue #307 · Microsoft/BashOnWindows)。PandocはHaskellで書かれていて、GHCコンパイラーでコンパイルされたHaskellプログラムはデフォルトでインターバルタイマーを使うそうです。スレッド(ユーザースレッド)の実装に使うんだとか。

 これを回避するには、GHCのRTS(runtime system)オプションで「-V0」を指定してインターバルタイマーをオフにします(上記issueをもとに検証)。

$ pandoc +RTS -V0 -RTS foo.md -t html -o foo.html

 RTSオプションは環境変数GHCRTSで指定することもできます。

$ export GHCRTS=-V0
$ pandoc foo.md -t html -o foo.html

追記(2017.2.11):

Windows 10のビルド14986で対応したとのこと。

 | HOME |  »

Categories

Recent Entries

Recent Comments

Recent Trackbacks

Appendix

emasaka

emasaka

フリーター。
連絡先はこのへん

Monthly


FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。