ゆたりんブログ

・何をしたいのか？ 日時データ(例 : 2017/11/6 8:10)が含まれるデータファイルの解析で、日付や時間を分離しておきたい。 例えば、以下に気象庁のサイトからダウンロードしてきた東京の最近1ヶ月の毎時気温データがあります。 ここから毎日の10時のときの気温だけを抜き出したい場合に、日付と時間が一つのセルに一緒に入っていると扱いが面倒。そこで表計算ソフトの機能を使って、セルの中の日付データを分離したいというわけです。 データとしてはここに示した気象庁からダウンロードしてきたものに限らず、日時を扱う場合に汎用的に使える方法を示していきます。 使用する表計算ソフトはLibreOfficeのCalcです。 ・手順としては2つ 日時を分離する方法は2つあります(もっとあるかも知れないけれど今回はこの2つ)。 1つ目は特定の記号でデータを分離する方法。 2つ目は関数で欲しいデータのみを抜き出す方法。 ・手順1 記号で識別して分離する方法 とりあえずサンプルデータとして次の日時データを用います。 2017/11/6 8:10:00  これをセルの書式設定で調べると、以下の書式コードとなっています。 さてこのデータを分離していくわけですが、Calcの機能としては「テキストから列へ(X)…」を用います。メニューバーの「データ(D)」を開くと見つけられます。  クリックすると以下のウィンドウが開きます。 ここで「区切りのオプション」を指定することで、任意の記号でデータを分離していくことが出来ます。ここでは日付(201711/6)と時刻(8:10)を分離するため、スペースで区切るよう指定しています。 分離すると以下の画像のようにB列に日付、C列に時刻に分かれます。B列の日付に0:00と時刻がくっついてきてしまっていますが、これは書式設定で時刻を含まないように指定しましょう。  ここまでで整理すると以下の画像のようになります。 次にC列の時刻の分離をしていきます。手順としては先ほどと同様。時刻の入っているセルを選択して「テキストから列へ(X)…」を用います。 さっきは区切りオプションはスペースで分離しましたが、時刻はコロン「:」でそれぞれ分離出来るので、それを指定します。区切

お化けとか呪いなんて非科学的なモノが存在するわけ無いじゃん、なんて思ってたけど、 それは逆に考えると 非科学的なモノが存在するのならお化けも呪いも存在することになるっていう…。 そんでもって人間の想像力なんてその最たるもので、いくらでも非科学的なモノを創り出してしまう。 それが単に個人の脳内にしかない産物ならそれまでだけど、メディアやらコミュニケーションやらなんやらで伝達・交換がなされていくとあたかもそれが本当にあるかのようになってしまう。空想の産物だとしても根っこはリアルの「何か」と結びついているわけで大勢で探せばそれが本当であるという欠片くらいはすぐに見つかり、本当であるという認識が強固になっていく。そうして本当であるという前提を元にいろいろリアル側に生み出されていくと、やがては本当のモノになっていく。 まぁどっかの誰かが空気を読まずにネタばらしすれば一瞬で終わるだろうし、それでも終わらないのならそういうものとして残っていくかそれとも科学の進歩で解明されていくかのどちらか。 しかし「何かを信じる」なんてのは人間の内面の最たるモノ。そう簡単には当事者が解明を許されるものでもない。 世代交代でも引き継がれるレベルのものは文明が滅びるのを待つか、それとも最近流行りのAIさんにお任せすることになるか、はてさてどうなることやら。 AIがお化けや呪いを生み出して、それを人類が消費しているなんて未来もありそうだ。

最近はPython(プログラミング言語)をちょこちょこ書いています。まだTurtleでお絵かきして遊んでいる程度で、たまにYoutubeに動画を上げたりもしています。 こんなのとか↓ さて、一応参考書は手元にあるのですが、それでも分からないときはWebサイトを検索してソースコードの書き方などを参考にすることもあります。サイトによっては同じ処理でもソースコードの書き方が違うことはあります。ただ書き方ではなく、書式自体がまったく違うというケースもあります。 例えば、「mathモジュール」を読み込んで「sin()関数」を使うというケースでは a = math.sin(i) という書き方の他に a = sin(i) という書き方も出てきます。 そしてmathモジュールの読み込み方に関しても、 import math と from math import * (またはsin()関数だけならfrom math import sin) という書き方が出てきます。そしてこのimportの書き方に対応した関数の書き方をしなければ、sin()関数を使ってもエラーとなってしまいます。ちゃんと使うには 「import math」と書いてmathモジュールを呼び出した場合は「a = math.sin(i)」 「from math import *」と書いて呼び出した場合は「a = sin(i)」 と書く必要があります。 両方ともちゃんとsin()関数は読み込めているので処理自体は同じになるわけですが、後者の方は「math.」と書かなくてもいいので楽といえば楽です。しかしこれは弊害もあって、いくつもモジュールを読み込んだ場合、その中に同じ名前の関数があると何のモジュールの関数を使っているのか分からなくなってしまいます。 (実際にはモジュールを読み込む順番で何の関数が使われるかが決まるとかなんとか？) 自分は初歩の段階でこの点が良く分からずに少しつまづいてしまいました。こういうことを踏まえておけばもう少しスムーズに調べものが出来たかと思います。 (まぁ初歩のうちはアレコレ調べ過ぎずに、参考書などをやり切った方がいいと思いますが) 実際にモジュールを読み込んで使うときは、ケースバイケースで使いやすく後から読んでも分かりやす

【結論】 以下、長ったらしく文章を書いてますが、結論としては cronで指定するスクリプトファイルにはちゃんと実行権限を付けること です。 参考 : How to set a cron job to run a shell script? - Ask Ubuntu またUbuntuではcronのログは /var/log/syslog に出力されるようです。 CronHowto - Community Help Wiki 下の話はそこに行き着くまでの経緯なので、興味があったら読んで見てください。 趣味と実験の一環としてWebカメラを使ってタイムラプス動画を撮ったりしています。最近のだとこんな作品になってます。 これはWebカメラを接続したパソコンで制御して連続写真を撮ってるんですが(ここではcronは使っていない)、たまーにWebカメラが認識しなくなって撮影が失敗していることがあります。一度撮影をセットしたら後はほぼ放置しているので、失敗したらその日の撮影はおじゃんとなります。また失敗していることに気が付いても、大抵は数時間後になんとか分かる程度。撮影を再開しても数時間分の撮影データはロストしていることになります。毎日タイムラプス動画をYoutubeにアップロードしているように見えてたまに日付が飛んでいるのは、そういった失敗によるものです。 ここまでは前置きで、ブログタイトルにあるcronの話はここから。 まずWebカメラが認識しなくなって撮影が失敗すると、撮影に使用しているプログラムがエラーをログファイルに出力します。撮影が順調に進んでいるかどうかを確認するには、常にログファイルを監視してエラーがないことを見ていればいいわけです。さて、監視すればいいとはいっても付きっきりで見ているわけにもいかないので、ここでcronを使ってログファイルにエラーが出力されているかどうかを定期的に調べればいいという算段です。 処理としてはそう難しい話ではなくて、単にgrepコマンドでエラーメッセージを拾うようにすればいいだけ。それをスクリプトファイル化してcronで数分毎に実行することで、撮影が失敗してるかどうかをチェックすることが出来ます。 (実際にはチェックに引っかかったらメールや通知を飛ばす処理や、自動的に撮影再開出来るように

Open Babelとは？ 化学関係では分子などを記述するための多くのファイル形式がありますが、Open Babelはファイルを別の形式のファイルに変換することが出来るオープンソースソフト及びライブラリです。 分子モデルのファイルを読もうとしてその形式がソフトで対応していない場合でも、Open Babelで読み込める形式に変換するといった使い方が出来ます。またソフト自体がOpen Babelのライブラリを組み込んでいて、特に気にせずに様々な形式のファイルを読めるなんてこともあります。 Open Babel誕生までの簡単な経緯 Open Babelはその名前から分かるように、Babelというプログラムに由来しています。 BabelはPat Walters氏とMatt Stahl氏により書かれたプログラムです。その2人がBabelを新たに書き直そうとスタートしたのがOBabelとなります(完成はしなかった模様)。 そしてOpenEye社がGNU GPLライセンスでMatt氏のアイデアも加わったOELibというものをリリースします。 その後OELibはOpenEye社により書き直され、それは現在OEChemと呼ばれています。しかしこのソースコードは公開されていません。そしてオープンソースのOELibはOpen Babelに名前を変えて現在に至るという状況のようです。 ここまでの話は時期的には2000年代初頭の流れのようです。 またその他にOELibから派生したものとしてJAVAで書かれたJOELibがあります。 参考サイト Frequently Asked Questions - Open Babel OpenEye Scientific Software - Wikipedia Open Babel - Wikipedia JOELib - Wikipedia

何回かオープンソースのAvogadroというソフトを使って3Dの分子模型を作ったりしてますが、ちょっと興味が湧いたのでそこで使われるファイル形式について調べてみることにしました。   分子モデリングソフト Avogadro を使ってみる   カメムシ襲来！(秋の風物詩) 3D分子モデリングソフトで使われるファイル形式はかなり多岐に渡っているのですが、今回はその中のxyzフォーマットのファイルについて見ていきます。 以下はAvogadroで作成したヘキサナール分子をxyzフォーマットで出力したものです。 19 Energy: -1.2963865 C -3.10801 1.54119 -0.01611 C -1.98911 0.51172 -0.00651 H -3.03107 2.21469 0.84346 H -4.08177 1.04347 0.02813 H -3.07614 2.14423 -0.92919 C -0.61452 1.17987 -0.00730 H -2.09119 -0.13997 -0.88185 H -2.09142 -0.12093 0.88305 C 0.50986 0.14459 -0.04847 H -0.51212 1.80130 0.89074 H -0.52732 1.84741 -0.87328 C 1.87735 0.80789 0.07828 H 0.45643 -0.42368 -0.98560 H 0.37858 -0.58071 0.76438 C 2.97498 -

秋と言えば比較的温かい日にどこからともなくカメムシがやってきます。今年も例にもれず、先日網戸に何匹かくっついていました。 カメムシについて簡単に解説しておくと カメムシはカメムシ科の昆虫の総称で、キンカメムシ、アオクサカメムシ、ナガメなどがいます。俗称としてはヘッピリムシ、屁こき虫、クサムシなどがあります。個人的にはヘッピリムシという呼び名をよく耳にします。またその俗称から分かるように、触ると悪臭を放つ虫です。家の中に入ってきたのを捕まえようとするとすぐ悪臭を放つので、なかなか厄介です。一度悪臭を出されると、カメムシを外に放り出してもしばらくは臭いが残ってしまいます。 ちなみに英語では「stink bug」と呼ばれています。「stink」は悪臭という意味でもあります。 その悪臭の主成分はヘキサナール(青臭さ)、トランス-2-ヘキセナール(草や葉の匂い)のようです。臭い成分に関しては諸説あるようで、カメムシの種類によっても違うのかも知れません。詳しくはカメムシや臭い成分分析の文献や論文を調べる必要があるでしょう。 簡単に臭い成分について触れておくと、ヘキサナールは分子モデルで表すと次のようになります。 高画質版をYoutubeにアップロードしています。 3D分子モデル : ヘキサナール / Hexanal - YouTube またトランス-2-ヘキセナールに関しては以下のようになります。 高画質版はこちら 3D分子モデル : トランス-2-ヘキセナール / trans-2-Hexenal - YouTube 両方の分子ともに炭素原子が6つ、酸素原子が1つと構造が似ていますが、結合が若干異なります。 さてカメムシのお話に戻ると、秋は越冬のため人家に飛来することはあるそうです。外に洗濯物や布団を干しておくと、それにくっついて洗濯物などを取り込んだときに一緒に室内に入ってしまうということもあります。 ※以下、カメムシの写真や動画があるので、嫌いな方は読むのはここまでにしておいた方がいいでしょう… さて、いつもは見つけたらすぐ外へ逃がすだけですが、ちょっと捕まえてその様子を見てみることにしました。網戸に張り付いているカメムシを空いているペットボトルに捕まえました。アップで撮るとこんな感じ。結構たくましい。 捕

はじめに Emacsにはいくつかフォントの設定方法があります。今回はまず簡単な方法から紹介していきます。古い方法に関してはかなり把握するのが面倒ですが、記録的な意味で一応触りだけ書いておきます。 今回の話は Emacs 24.5.1 Ubuntu 16.04.3 LTS GNOMEデスクトップ環境 で確認をしています。 メニューから選ぶ方法 Emacsでも最近のエディタと同様に、設定メニューからフォント変更が出来ます。 メニューバーの「Options」から「Set Default Font…」を選ぶと次のようなフォント選択画面が出てきます。 ここから好きなフォントとサイズを選ぶと、すぐにその設定が適用されます。しかしこの状態ではEmacsを終了すると、また元の設定に戻ってしまいます。設定を保存するにはメニューバーの「Options」から「Save Options」を選択します。これによりEmacsの設定ファイルにその設定が書き込まれるので、Emacsを終了してもその設定は維持されます。 もし設定を破棄したい場合は、設定ファイル(~/.emacs.d/init.elなど)に書かれた設定を削除するとよいでしょう。 設定ファイルに自分で書き込む方法 自分で設定ファイルに直接書きたい場合、以下のような記述で書くことになります。 (add-to-list 'default-frame-alist '(font . "Takaoゴシック-12" )) この例ではTakaoゴシックというフォントを12ポイントのサイズで指定しています。またフォントサイズの後ろに細かい指定(太字、イタリックなど)も出来ます(詳しくは公式のドキュメントを参照)。また、記述の仕方では"Takaoゴシック 12"といった書き方も出来ます(スペースで設定を区切る方法)。 なお、これら指定方法は、初めに紹介したメニューから選ぶ方法とは設定ファイルの記述が違ってきます。たぶんどちらも同じ設定になると思うのですが、違いが気になる方は調べてみて下さい。 どのようなフォントが使えるかを選ぶには さて設定ファイルに自分で記述する方法では、使いたいフォント名を調べてくる必要があります。正確にフォント名を記

GNOMEデスクトップ環境でウィンドウを画面右半分、左半分に移動するキーボード・ショートカット Ctrl+Super+右矢印キー Ctrl+Super+左矢印キー があったのだけど、なぜか Super+右矢印キー Super+左矢印キー でも同じ動作をしてしまっていました。別のソフトのキーボード・ショートカットの設定でその組み合わせを使おうと思っていたので、修正を試みることに。 GNOMEのこのキーボード・ショートカットの設定を他のキーに割り当てても直らなかったのだけど、一度キーボード・ショートカットの割り当てを「無効」にして再び再設定することでどうやら直った模様。おそらく設定ツールからは変更出来ない場所に何らかの設定が残ったままだったのが原因だったのかと思います(ホントにそうだったという確証はないですが)。 これでウィンドウの移動は一番初めのキーボード・ショートカットで動作して、Superと矢印キーの組み合わせでは何も起きない状態に出来ました。また他のソフトにSuperと矢印キーの組み合わせを割り当てても問題無く動作するように出来ました。

GNOMEデスクトップ環境を使っていて、画面の表示などが何かおかしくなった時に簡単に起動しているソフトなどそのままでリセットする方法があります。GNOME Shellをリスタートするという方法で、キーボードで Alt + F2 を押して、表示されるダイアログに r とだけ入力してエンターキーを押します。これでGNOME Shellがリスタートされます。またこの方法では使用しているソフトはそのままの状態に保たれるようです。 実際に試したときの様子のGIFアニメは以下のとおりです。 ログインし直すというのはよくある方法ですが、だいたいの場合はこの方法でも解消するかと思います。 なお、"r"というのはコマンドではなく、Alt+F2で表示されるダイアログにおいて有効な機能のようです。なので通常の端末に"r"と入力して実行しても何も起きないでしょう。

2017年9月6日発生の太陽フレア現象に関するその後の情報についてまとめてみました。 まず国土地理院の発表。 9月6日に発生した太陽フレアのGPS測位への影響（速報）｜国土地理院 9月8日の日中、スマホやカーナビ向けのGPSによる測位精度が悪くなった時間帯が生じたそうです。また専門的な利用向けのGPSの測位精度に関しては、そういった影響を軽減する仕組みがあるようで、これまでのところ影響はないそうです。 次に国立天文台の発表。 ｢ひので｣による大規模太陽フレアを起こした活動領域の観測について | 科学衛星｢ひので｣ 太陽観測衛星ひのでによる観測データがまとめられています。今回の太陽フレア現象でもいろいろとデータが取得出来たとのことなので、より詳しい研究につながっていくと思われます。リンク先にはひのでにより撮影された動画と、太陽フレア現象自体の解説動画が掲載されています。より深く太陽フレア現象について知りたい場合は参考になるかと思います。 太陽で起きた現象が地球に影響するということは当然日本だけの話ではありません。 NASA( National Aeronautics and Space Administration: アメリカ航空宇宙局)も次のような情報を出しています。 SDO | Solar Dynamics Observatory Sun Erupts With Significant Flare | NASA (9月6日以降の情報も書かれています) こちらはイギリスの複数の大学の観測チームの情報。 Scientists observe largest solar flare in 12 years

ここ最近、何回かブログでWebカメラやfehコマンドについて書いてます。そしてWebカメラで定点撮影している写真で最新のものを確認する時に $ ls | tail -1 | feh -f - -g 500x400 とすればコマンド一行で最新の写真が表示できます。便利便利。 さて、このコマンドは写真が入っているフォルダにて実行する必要があります。それはなぜかというと、例えば別のフォルダにいる状態(写真はwebcamフォルダに入っていて、いまいるのはその一つ上のフォルダ)だと以下のコマンドではファイル名しか受け取れないからです。 $ ls webcamフォルダ | tail -1 現在居るフォルダには当然そのファイルは存在しないので(写真はwebcamフォルダに存在する)、その出力をfehコマンドに渡してもエラーが表示されてしまいます。 そこで別フォルダにいても最初に示したコマンドを有効にするには、ファイル名だけでなく相対パスが付いた状態のものをlsコマンドで出力する必要があるわけです。 そしてlsコマンドには"-d"オプションがあり、これを用いることで相対パス付きでファイル名を出力することが出来ます。このオプションは使い方が少し独特でファイル名に相対パスを付けて出力したい場合は $ ls -d webcamフォルダ/* とフォルダの後ろにワイルドカードを付ける必要があります。これでwebcamフォルダ内のファイルが相対パス付きで表示されます。そして、これを最初に示したコマンドに適用すると $ ls -d webcamフォルダ/* | tail -1 | feh -f - -g 500x400 となります。これによりたとえ他のフォルダにいたとしても、コマンド一行で最新の写真が確認出来るというわけです。 今回の話はfehコマンドに絡めたものですが、このlsコマンドの使い方はその他にもいろいろと応用できるかと思います。

エディタに何を使うかと言えばVimかEmacsかで、たまに論争になったりもします。 (参考情報 :  エディタ戦争 - Wikipedia ) 幸い（？）にも自分はこれまでそのような論争に巻き込まれたことはありませんが、初めてLinuxを使おうとしていた頃は何を使うかで迷っていたものです。まぁ最近ではいろんなエディタが登場してきていて、テキストエディタからソースコード編集に特化したものなど様々なものがあります。 さて、Vimの話は置いておいて(Vimは実際によく知らないので)、Emacsの話をしていきます。 GNU Emacs - GNU Project Emacsの特徴といえばその拡張性です。ブラウザやメール、画像を表示したりカレンダーを見たりゲームが出来たりもします。まぁ、出来ると簡単に書きましたがそれは使いこなせる状態にまでなったらの話で、通常はそれ用のソフトを使った方が便利です…。またエディタとしても操作感は結構クセが強いため、Windowsのメモ帳みたいに考えていると面食らうかも知れません。それでも最近のEmacsはマウス操作である程度出来るようになっています。ただしやはりEmacsはキーボードからの操作がキモになってくるので、少し慣れてきたらそっちの操作を覚えていく必要があります。それとEmacsを他のテキストエディタと同じようなキーボード操作に設定することも出来ますが、なるべく早くEmacsの操作体系に慣れていった方がいいかと思います。 さて、実際何を読んでEmacsを覚えていけばいいかになりますが、Webに数多くあるEmacs便利情報は細切れのものだったり初心者にはハードルが高いものだったりします。一冊、Emacsの初心者向けの本を買ってきて、それを通して一通り覚えるのが確実だとは思います。また、一番初めに触るマニュアルとしてはEmacsのヘルプに付いてくるチャートリアルが便利です。 このチャートリアルの表示の仕方については以下のGIFアニメを参照して下さい。 ここに書いてある操作を身に付ければ、一通りEmacsのキーボード操作は出来るようになるでしょう。 その次の段階としては、自分用に使いやすいカスタマイズや、その他の便利なパッケージを入れる方法になってきます。以前は、そういった設定は設定用ファイルに自分で書いていった

※以下の話はUbuntu16.04.3のGNOMEデスクトップ環境で試したときのものです。他の環境については必要に応じて試してみて下さい。 Emacsを使っていて説明用にスクリーンショットや動画を撮りたいとき、ウィンドウタイトルにファイル名やらユーザー名やらマシン名やらが表示されてしまっていて後から修正が必要になってくる場合があります（何が表示されるかは設定による）。 どこに公開されても問題ないものなら特に対処する必要はないのですが、後々めんどくさいことになると厄介。また、一々設定ファイルでウィンドウタイトルに表示させたいものを変更させるのも若干手間がかかります。 そこでEmacsのコマンド(ミニバッファで実行するヤツ)でサックリ変更する方法について書いておきます。実行するコマンドは以下の通り M-x set-frame-name <RET>タイトルを入力<RET> です。 <RET>は独特の書き方ですが、エンターキーを叩くって意味です。変更している様子を撮ったGIFアニメを以下に貼っておきます。 この方法なら、さっとスクリーンショットを撮りたいときでもすぐ変更出来ますね。 ただし、いざそういう場面になったときそのコマンドを思い出せるかどうかは記憶力次第…。なので、自分で見つけやすい場所にメモとして残しておくといいかと思います。 あとGIFアニメ内に書いてあるように、WindowsやMacでも同じ方法が使えるかどうかは調べてません。 関連ブログ記事 wmctrlコマンド - ウィンドウタイトルの変更操作について

前回のブログの太陽フレア現象の話 太陽フレア現象(2017年9月6日発生)関連のお話の用語をいくつか その続きというか、再び大きな太陽フレア現象があったそうです。NICTの発表は次のリンク先に。 大型太陽フレアの観測に関するその後の状況（2） | NICT-情報通信研究機構 発生日時は2017年9月11日の00時35分。 太陽フレア現象で飛んでくるコロナガスが地球に到来するのが9月12日の未明から午後早くにかけてだそうです。約1日ちょいかかって地球にやってくるってところでしょうか。 あとは今回の太陽フレア現象を起こしている黒点群が太陽の反対側に移動していくので、今後は影響が少なくなっていく的なことも書いてありました。

先日のibusのブログの話の続きで、もう少し試して使ってみています。 (この前の話 :  日本語インプットをfcitxからibusに切り替えようとしたときの作業記録(Ubuntu 16.04.3) ) 今回も結論から言うと、ibusでもほぼ使い難いということは意識せずに、普通に日本語入力が出来るところまで持ってこれました(あくまでも自分の個人的な使い方の範疇において)。操作状況を動画にすると以下のような感じになります。動画中で入力している文章ではなく、日本語入力の切替(Shift+Spaceを切替設定に割り当て)について見ていただければと思います。 さて結論や動画はひとまず置いておいて話を始めていきます。 指摘を頂いたりWebで調べていると、どうも英語入力と日本語入力を切り替えて使うだけなら、入力ソースで「英語」と「日本語(Mozc)」を行ったり来たりする必要はなくて、Mozcだけに固定したままでいいようです。 Mozcの入力モード自体に 直接入力、ひらがな、カタカナ、半角英数、… などがあるので、その中でモードチェンジしながら使うという方法です。 ibus自体には"入力ソース"を切り替えるキーボード・ショートカットがあるので、それを使って「英語」と「Mozc」を切り替えることは出来ます。他の中国語や韓国語などのIMEを追加していけば、それらを切り替えながら使うということも出来ます。 ただ、先日のブログの話で挙げたように 入力切替時のポップアップの抑制 Mozcの初期状態の維持 あたりの話があるので、状況によってはこの方法では使い難い面はあります。 そして、これはMozc側のモードチェンジにより英語と日本語入力を切り替えればほぼ解決することになります。 というあたりまでは、アタマの中でストーリーが組み上がったわけですが、実際にそのMozc側のモードチェンジがスムーズに出来ないのであれば実用的とは言えません。ということで、そのあたりを詰めていってみることにしました。 で、なんやかんやでアレコレやってみた結果として、以下の設定になりました。 これMozcのキー設定の画面なんですけど、そこに 「直接入力」　に対して　「IMEを有効化」 「入力文字なし」　に対して　「IMEを無効化」

タイトルにあるように、日本語インプットに使うシステムをfcitxからibusに切り替えようと思った時の作業記録です。 手順の解説記事ではないので、やり方(method)を知りたい人は読んでもあまり役には立たないかと。 そして結論から言うと、ibusやmozcの設定やなんやらいじるのがめんどうだったので結局fcitxに戻しています。 まず環境としてはUbuntu 16.04.3 LTSですが、デスクトップ環境にGNOMEを使っています(Unityではない)。また日本語入力に関してはMozcを使っています。 手始めにGNOMEのシステム設定から「言語サポート」を開き、使用するインプットメソッドをfcitxからibusに切り替えました。ここで一旦ログアウトします。そしてログインし直しましたが、この時点ではMozcには切り替えられず。再びGNOMEのシステム設定から「地域と言語」の入力ソースに日本語(Mozc)を追加します。が、しかし、日本語の追加項目はいくつか出てくるのですが（Anthyとか"かな"とか）、Mozcは出てきません。どうもMozc用のパッケージが不足している模様。とりあえずターミナルで   $ apt search mozc で検索。そしたらibus-mozcパッケージがインストールされてなかったことが分かりました。あとはいくつかWebサイトを読んでこのパッケージが必要なことを確認し、パッケージをインストール。これで日本語の追加項目にMozcが表示されるはず、と思ったのですが、設定を開いてもそんな項目は表示されませんでした。 さて、いったい何が足りないのか？ と思ったのですが、なんてことはなくパッケージを有効にするにはいったんibusのデーモンを起動し直す必要があったようです。ってなわけで、ibusを起動し直すとちゃんとMozcが表示されて、追加も出来ました。一応ここで一度ログインし直し。 さて、これでibusが使用出来るはずなのですが、そういえば入力切り替えのキーボード・ショートカットの設定をしていませんでした。 この時点で結構めんどくさい気持ちが出てきたのですが、気を取り直してGNOMEのシステム設定「キーボード」でショートカットの「タイピング」項目で「次の入力ソースへ切り替える」で「Shift+Space」を設

太陽フレア現象自体は規模の大小はあるようですが、2017年9月6日に起きた太陽フレア現象は特に規模が大きいものだったようです。そしてその太陽フレア現象により放出されてコロナガスが地球に到達することによる影響を懸念するニュースがいくつも報道されていました。磁場の乱れによる影響のピークは9月8日の午前中だったようです。また太陽活動については活発な状態なようなので、しばらくは注視する必要があるとかなんとか。 (Web上のニュース記事はしばらくするとリンク切れになってしまうので、今回は貼りません) 注意喚起自体は国立研究開発法人の情報通信研究機構( NICT )から出されていました。 プレスリリース | 通常の1000倍の大型太陽フレアを観測 | NICT-情報通信研究機構 で、まぁこの手の話について詳しくはなくてニュースを読んでいてもまず用語からしてちょっと聞きかじった程度。ということで、この機会というのもなんですが、いくつか用語とその意味を調べてみました。 とりあえず、メモ程度の話としてブログに残しておきます ・太陽フレア現象 : Solar flare 　  太陽表面での爆発現象 ・コロナ質量放出 : Coronal Mass Ejection(CME)  　 コロナのガスが宇宙空間に放出される現象  　 地球に達すると、通信障害、磁気嵐、オーロラが発生する場合がある ・コロナ : Corona 　  太陽の最外層の部分 ・太陽風 : Solar Wind 　  太陽コロナから放出されるプラズマ流。放出される粒子は陽子、電子など。 追記 2017年9月9日15時53分 起きた事象としては 1. 太陽の表面で太陽フレア現象が起きる。 2. 太陽フレア現象でコロナガスが宇宙空間に放出される。 3. そのコロナガスが地球に到達する。 4. 地球に到達したコロナガスが地球の磁場を乱す 5. 乱れた磁場の影響でなんやかんや起きる みたいな感じでしょうか。 また、コロナガスが地球に到達する前に光が地球に到達するので、そこから規模を見積もってるようですね。何か影響が出る前に事前に注意喚起が出来たのはそのためかと。

EmacsのOrg-Modeにはソースコードを扱えるコードブロックという機能があります。これは単にソースコードを書くだけでなく、Emacs内で実行してそのまま出力も得ることが出来ます。コードブロックは #+BEGIN_SRC sh echo 1 #+END_SRC こんなように簡単に書けて、これをコード内で実行(C-c C-c)するとコードブロックの下に #+RESULTS: : 1 と出力されます。この例では「sh」と指定してshellコマンドを実行していますが、他にもemacs-lispやpython、gnuplotなども指定して実行することが出来ます。 実行するには当然システムの方に指定したコマンドがインストールされている必要があります。また、実際にソースコードを実行するにはEmacsの設定ファイル内でどのプログラムを有効にするのか指定する必要もあります。もしコードブロックを書いても何も実行されない場合は、そのへんの設定を洗い直す必要があります。 (そのあたりはまた別でブログに書こうと思います) もう少しこの機能で遊んでみると、以下の動画のようにEmacsに書いた文章を喋らせるといったことも出来ます。これはコードブロック内でOpen JTalkという日本語音声を喋らせることの出来るコマンドを実行しています。 この例では若干コマンドが長くなっていますが、そのへんはシェルスクリプトを作るなどすればもっと簡単に書けるかと思います。テキストエディタであるEmacs内でそのまま実行出来るわけなので、使いようによってはおもしろいことも出来ると思います。 Org-Modeについてはその他にも数多くの機能があって実際結構役に立つことが多いので、また何かネタがあったらブログに書いていこうと思います。

Emacsで文章を書いている時に、文の先頭にあるスペースを削除したい場合があったとします。 具体例としてはOrg-modeでplain textにエクスポートしたとき、見出しのレベルに応じて段落がスペースによって字下げされるといったことがあります。それはエクスポートの書式設定で対処すべき話なのですが、設定項目を探すのに時間がかかったりする場合もあるので、今回はEmacsの文字列置換機能で対処する方法を考えてみます。 例として次のような文章について考えてみます(文章の内容は特に意味はないです😜)。 この文章では2行目と3行目の先頭にそれぞれ2つの半角スペースが入っています。 これくらいならDeleteかBackspaceで消せば簡単に済みますが、一括して消せる方法を覚えておけば処理すべき数が増えても簡単に対応できます。 Emacsにはいくつかの置換機能があるので、その中から正規表現でパターンマッチングして一括で処理するreplace-regexpという方法を使います。 コマンドは M-x replace-regexp として、その後に置換したいパターンを入力してエンター。次に何の文字列に置き換えるかを入力してエンターとすると一括で変更されます。 上の例文で先頭の2つの半角スペースを消すには M-x replace-regexp <RET>^  <RET><RET> とします。<RET>はエンターキーを押すことを現しています。 この書き方では分かりにくいのですが、まず置換したいパターンに 「^  」(サーカムフレックス + スペース + スペース) を指定しています。そして今回は置き換えるのではなく、削除するので後半は何も入力せずエンターキーを押しています。 (サーカムフレックスは別名キャレット、ハット記号とも呼ばれる) 一連の操作を動画にすると以下のようになります。 サーカムフレックスは行の先頭を指定するもので、これがあると先頭にあるものだけ置換対象に選ぶことができます。 以上の方法ではコマンドを実行するとすぐに一括で置換されますが、一つずつどれを置換するか確認しながら行える方法もあります。

 Linuxでコマンド操作をするときに使う端末ソフト。これにはタブ機能を持つものもありますが、どうも個々のタブの操作の履歴に関しては、別々のhistory listに記録されていくようです。 (ただしタブや端末の終了時には大元のhistory fileに記録される模様) つまり端末で実行したコマンドを別のタブでhistory機能で呼び出そうとしても、そのままでは呼び出されないことになります。history機能はbash実行中でもhistory fileへの実行履歴の書き出し、読み込みといったことも出来ます。これらを組み合わせて常にどこで開いているタブでも履歴を共有化するといったことも出来るようです。 このへんはネットで検索するとそういった方法がいくつか見当たりますが、自分で試したわけではないので、そういう話もあるということで終わりにします。 また端末のタブ機能だけではなくscreenやtmuxといった環境でもこういった事情は考慮しておく必要があるかも知れません。 結局はbashがタブごとに別々のプロセスとして実行されるため、履歴が分離しているのだと思います。とりあえず今回は以前から少し気になっていた動作について少し調べた程度の話ですが、また何か分かったらブログに書いていきたいと思います。 historyに関しては以前、こんなブログも書いてます。 historyコマンドでbashのコマンド履歴が途中までしか探れない場合について

Bash Reference Manual: Bash Variables によると、コマンドの先頭にスペースを付けて実行すると、実行されたコマンドはhistoryには記録されないようです。 これはbashの環境変数の「HISTCONTROL」に「ignorespace」や「 ignoreboth 」といった値がセットされている場合にそのように働きます。 Ubuntuの場合、この環境変数は ignoreboth に設定されているようです。ホームディレクトリの .bashrcファイル に書かれているので確認してみて下さい。 使い方としては、例えばディレクトリ内のファイルを全部消す操作として「rm *」と実行するとします。ただ他のディレクトリにいる状態で、history機能をうっかり誤操作して再びこのコマンドが実行されてしまうと洒落では済まない事態になってしまいます。このように動作がクリティカルなコマンドを実行するとき先頭にスペースを付けるクセを付けておけば、historyに記録されないため危険性を減らすことが出来ます。 (コマンドの実行履歴を記録するという目的ではあえてそのような記録を残すというのも必要ですが) 後はどこぞのWebサイトからコピペしてきたコマンドを実行したときに、なぜかhistoryに記録されてないといったときには、コピペした文の先頭にスペースが入っていた、なんてこともあります。 このような機能、使うにしろ使わないにしろ、bashのhistoryにはそういった機能もあるということをアタマに入れておくと何かの役に立つかも知れません。

これは空のタイムラプス動画を作る時に撮影した画像から30分毎に撮影したものだけを抜き出して作ったものです。これをLinuxのコマンド操作で作ってみることにします。 (環境 : Ubuntu 16.04.3LTS) パターン指定で特定の画像だけを表示させられる画像ビューアでも同じようなサムネイル画像は作れますが、今回は以前紹介したfehというコマンドを使います。 (以前の記事 : fehコマンドのモンタージュモード(サムネイル作成) ) サムネイル画像の作り方は以前書いた通りですが、今回は30分毎の画像だけを抜き出すという操作と組み合わせます。 まず対象とするファイルは以下のようなものになります。 webcam-20170824-124815.jpg webcam-20170824-124830.jpg webcam-20170824-124845.jpg webcam-20170824-124900.jpg webcam-20170824-124915.jpg webcam-20170824-124930.jpg webcam-20170824-124945.jpg webcam-20170824-125000.jpg webcam-20170824-125015.jpg webcam-20170824-125030.jpg webcam-20170824-125045.jpg webcam-20170824-125100.jpg webcam-20170824-125115.jpg ここでファイル名の命名規則は「webcam-撮影年月日-撮影時間.jpg」となっています。 30分毎の写真を探すとき、例えば12時では12時00分と12時30分の写真を探すとします。これをfindコマンドで書くと、 find ./ -name 'webcam-*-12[03]000.jpg' となります。今回は12時以外の時間のものも対象とするので、それを踏まえて書き直すと find ./ -name 'webcam-*-??[03]000.jpg' となります。これで対象となる画像のファイル名は取得出来るのですが、出力されるファイル名の順番がバラバラになっています。サムネイル画像にするためには時

1年は平年では365日。うるう年では2月に1日加わって366日です。さて、1年は12ヶ月ありますが、毎月の日数は30日だったり31日だったり2月は28日(or 29日)だったりと違いがあります。 単純に考えると、この違いが毎月の集計に現れることになります。 お散歩の歩数を測っているとき 朝食やおやつに食べるバナナの本数を月ごとに数えるとき 毎月の売り上げを集計するとき ブログや動画のアクセス数を集計するとき などなど、いろいろ関係する話はあります。まぁ30日間と31日間では1日しか違いがないのであまり気にしなくていいかも知れませんが、ここで改めて確認してみることにします。 まず1年の日数を月ごとに書くと以下の表のようになります。 これをグラフにすると次のようになります。  大雑把に眺めるとだいたい同じくらいの日数に見えますが、どれくらいの違いがあるのか見てみることにします。 まず1年は365日。これを年間の月数12で割ると、1ヶ月は平均で30.4266.....日となります。毎月の日数がこの平均値と比較してどれくらいの割り合いなのかをグラフにすると以下のようになります。 (例えば8月では31日間なので、 31/平均値 ≒ 1.02 という計算です) そのままでは違いが分かりにくいので拡大した図を挿入してあります。2月は28日間と他の月と比べても少ないので差が大きく出ています。また他の月でも違いが見て取れます。 ここまでの話から、毎月ごとの集計では日数の違いにより若干の違いが生じてくるということが分かると思います。仮に毎日バナナを2本食べていたとすると、それを集計すると月によって若干多かったり少なかったりしてくることになります。例えば、そういった集計をグラフにして見ると、毎日同じ本数のバナナを食べていてもグラフに月ごとの周期が乗って来ることになります。 ちょっとした集計ならそういった差は取るに足らないものですが、もうちょっと正確性が要求されるようなものだとこういった話も考慮していく必要があるでしょう。 さて、別の話としてこういった違いを除いて考える方法として、1年を1週間(7日間)ごとの区切りで考えるというものがあります。この場合は月ごとに日数が異なるのとは違い、7日間とキッチリ決まっているため同じ日

historyコマンドを実行すると、 1422 gvfs-open ./ 1423 dmesg 1424 top 1425 ls 1426 history | grep scp というようなような出力がされ、 $ !1423 と入力して実行すると、履歴にあるdmesgコマンドが実行されます。以前実行したことがあるちょっと長めのコマンドを再び利用したいときに便利です。 (頻繁に使うようならエイリアス作ったりメモしといたりした方がいいですが) さて、この機能は便利なのですが入力したらすぐに実行されてしまうので、確認や修正をしてから実行したい場合にはちょっと不便です。 (historyの出力からコピペして持ってくればいいわけですけども) 確認や修正をしてから実行したい場合、番号の後ろに「:p」と入力する方法があります。 Bash Reference Manual: Modifiers 上の例をこの方法で書き下すと $ !1423:p となります。この機能は番号のコマンドを実行せずに出力するだけです。ここではdmesgが出力されますが、入力行は空になります。そこで↑キー(もしくはCtrl-p)を押すと、入力行に出力されたコマンドが出てきます。後は確認なり修正なりして実行すればいいだけです。

端末でbashを使ってコマンド操作をしているときに、historyコマンドで過去に実行したコマンドを探ろうとしてもhistoryファイルに保存されているはずの分が出力されてこないケースがあります。 これはbashの環境変数のHISTSIZEとHISTFILESIZEの設定が間違っていることが考えられます。 (この環境変数はUbuntuではホームディレクトリ以下の.bashrcファイルに書かれている) まずbashのコマンド履歴の保管の仕方として、bashの実行中は「history list」に蓄積。そしてbashを終了したときに「history file」へ書き出す、というようになっているようです(詳しくはドキュメント参照)。そして再びbashを起動したときに「history file」から履歴情報を「history list」に読み込む、となっているようです。 (history fileは通常はホームディレクトリ以下の.bash_historyファイル) そして 「history list」のサイズはHISTSIZE 「history file」のサイズはHISTFILESIZE で指定されています。 ( Bash Reference Manual: Bash Variables ) つまりはHISTFILESIZEをいくら大きな数字に取っても、HISTSIZEがそれより小さければ途中までしか読み込まれないということになります。 実験として試しに HISTSIZE=10 HISTFILESIZE=2000 として設定を反映、そして端末(bash)を起動してhistoryコマンドを実行すると、historyファイルには2000件も保存されていても直近の10件のコマンド履歴しか出力されないことが分かります。 (設定の反映についてはsourceコマンドについて参照) 通常はHISTZIEとHISTFILESIZEをどちらも同じ数字で十分な大きさで確保しておけば、まず問題はないかと思います。 まぁ実のところ以前よく分からないままこの環境変数を適当に設定していてこういうようなことをやらかしていたんで、せっかくなのでそれをまとめてみたというお話でした。

Nautilus(ファイルマネージャー)で起きる少し変わった挙動について書いておきます。 なおThunarやPCManFMといったファイルマネージャーでも似たような挙動をするようです。 以下の内容はこの挙動について説明するためにあえて分かりやすい状況を作成して行っています。 環境 : Ubuntu 16.04.3 LTS, Nautilus 3.14.3 (2017年8月19日時点での話) まず次のNautilusであるフォルダを開いているときのスクリーンショットを見て下さい。 このフォルダには2つのファイルがあるのがわかります。 「test01.desktop」と「ふぃっしゅあぷり」 というファイルです。 ではこのフォルダを端末からlsコマンドで見てみることにします。結果は以下のスクリーンショットのようになります。 さて、何か結果に違いが出ています。Nautilusでは表示されていた「ふぃっしゅあぷり」というファイルが、lsコマンドからは見えていません。そして代わりに「test02.desktop」というファイルが見えています。 実は「test02.desktop」というのはUbuntuのランチャーにソフトを登録する時に使うファイルです(Ubuntuに限った話ではないですが)。これを適切な場所に置くことで、そのソフトがランチャーから起動出来るようになります。そして、どうやらNautilusではこの種のファイルはファイル名そのものではなく、ソフトの登録名で表示するようになっているようです。 「test02.desktop」ファイル自体は中身はテキストファイルで、ランチャーにソフトを登録する際に必要な情報が書かれています。中身は以下のようになっています [Desktop Entry] Version=1.0 Name=ふぃっしゅあぷり Comment=おさかなてんごく Exec=/home/yutarine/tmp/filenamedesktop-test/bin.bash Icon=/home/yutarine/tmp/filenamedesktop-test/fish.png Terminal=false Type=Application Categories=Utility;Application; この

回答にはGoogleアカウントへのログインが必要になります。 読み込んでいます...

Twitterのアンケート機能、ブログにツイート埋め込んだ場合も機能するかテスト Twitterのアンケート機能って、ツイートをブログとかに埋め込んだ場合も機能するのかな？アカウント情報取得出来ないから、無意味だとは思うけど — ゆたりん📡 (@Yutarine) August 19, 2017

調べものをするときに電子辞書として2014年に発売されたCASIOのEX-word XD-U9850を使っています。 XD-U9850 - 専門 - 電子辞書 - CASIO そこで使っていて思いついたり見つけたりした小ネタをいくつか紹介してみたいと思います。 USB給電 この機種ではUSB-ACアダプターとUSBケーブル(USB-microUSB)を使うことで、そこから電源を取ることが出来ます。そうすると電池が減る心配が少なくなるので、例えばオートパワーオフまでの時間を長く設定して常にすぐに検索出来るようにするといった使い方も出来ます。パソコンで調べものをしているときに、脇に電子辞書を置いておいてゆっくり辞書の方を読むといった使い方も出来るでしょう。 電池が切れる心配が(ほぼ)なくなるというのは、結構使っていて気分的な違いが出てきます。 (注意 : USB"充電"ではなく"給電"なので、セットしてある電池の充電は出来ません) 「シフトキー」を使って辞典/モードキー下段の辞典を選ぶ 辞典/モードキーを使うと、すぐにそれに割り当てられている辞典を開くことができます。 上の写真で「リーダーズ/英和大」のキーを押すと、「リーダーズ英和辞典」が開きます。そしてそのまま続けて同じキーを押すと、「ジーニアス英和大辞典」が開きます。 これはこれで便利なのですが、「ジーニアス英和大辞典」の方を使いたい時に2回キーを押すのは若干煩わしいです。 そういった場合、この機種では「シフトキー(下の写真)」を一回押してから「辞典/モードキー」を押すことで、下段に書かれた辞典をすぐに開くことが出来ます。 さて、下段の辞典を開くのに同じキーを二度押すのと、シフトキーを押してから辞典/モードキーを押すのでは、キーを押す回数は同じです。これでは特にメリットが無いように思えますが、この方法の利点は一回目にキーを押した段階で使わない辞典を開く必要がないということになります。 「リーダーズ/英和大」キーを押す場合について考えてみます。 辞典/モードキーでは   リーダーズ英和辞典→ジーニアス英和大辞典 という開き方になります。 これがシフトキー→辞典/モードキーでは   ジーニアス英和大辞典 がすぐ

ここ最近、掃除機をかけているときに「ヒューヒュー」と何か詰まってるような音がしてました。 初めは掃除機ヘッドに何か詰まってるのかと思い、一通り見てみましたが特に何も詰まってません。次に掃除機本体のダストボックスやフィルターも見てみましたが、そこも特に何もありませんでした。 ただ音がするといっても吸引力が落ちたといった感じもなく、普通に掃除機は使えていました。 そんなわけで、しばらくはそのまま 使ってたのですが掃除機を使う度に「ヒューヒュー」という音を聞かせられるのはちょっと気に障ります。ということでもう一度掃除機全体をチェックしていたら、ホースの途中にホコリの塊のようなモノが詰まってるのが見えました。詰まっていたのはホースの掃除機本体側で、普段はこの部分は外すことがないのでいままで分かりませんでした。 ホコリが詰まっていたのは次の写真の矢印で示した部分です。 おそらく音が出ていた原因もこのホコリが詰まっていることだと思います。 ということでさっそくホコリを取り除く作業を始めました。まずホコリは次の写真のように詰まっていました。 これはホースの先から写した写真ですが、目視ではよく見えていません。ライトで照らすことでハッキリ見えるようになりました。 さてホコリは見えてるのですが、すぐかき出せるような位置にはありません。そこで、ホースの反対側の口から長い棒を入れてホコリを押し出すことにしました。 手身近に細い突っ張り棒があったのでそれを使うことにしました。一番初めの写真にも写っていますが、次の写真のような棒です。 ※(注意) 無理やり棒を突っ込んで押し出すと余計にホコリが詰まって取れなくなったりホースが破損する恐れがあります。このような作業は状況をよく調べた上で自己責任で行うようにして下さい。 さて、棒を突っ込んでいくと何か引っかかっているような手応えがあり、何回か突いているとホースの先から次の写真のようなホコリが出てきました。ホコリやら髪の毛やら爪楊枝やらが絡み合っています。 次の写真は取れたホコリをホースの口に当ててみたものですが、取れたホコリの大きさが分かります。 これだけ大きいものが詰まっていたのに、掃除機としてはちゃんと使えていてホコリも取れていたのはなかなか不思議です。 ホコリや髪の

以前書いたクイズ 【問題】おまんじゅうはそれぞれいくつずつ売れたでしょうか？   と似たようなお話です。 あるお菓子屋のおまんじゅうの値段は 大まんじゅう : 1個 120円 小まんじゅう : 1個   35円 です。 お菓子屋のある日のおまんじゅうの売り上げは『7,420円』でした。 そして次の日のおまんじゅうの売り上げは『5,560円』でした。 さて、お菓子屋の中学生の息子が数学の勉強として、このおまんじゅうの売り上げから「大」と「小」のおまんじゅうがそれぞれいくつずつ売れたのか計算してみることにしました。 まず「大まんじゅう」が売れた個数を「x」、「小まんじゅう」が売れた個数を「y」としました。そして初めの日の売り上げから 120x + 35y = 7420  … (1) の(1)式が出来ました。 同じように次の日の売り上げから式を作ると 120x + 35y = 5560  … (2) が出来ました。 そして(1)式と(2)式の連立方程式を解くために(1)式から(2)式を引くと、xとyが両方とも消えてしまい 0 = 1860 となってしまいました。両辺がまったく別になってしまい式としてもおかしいです。 結局、お菓子屋の息子は「大」と「小」のそれぞれおまんじゅうが売れた個数を求めることが出来ませんでした。 【問題】 さて、ではなぜお菓子屋の息子はそれぞれのおまんじゅうが売れた個数を求めることが出来なかったのでしょうか？