macのrubyで文字コードcp932でファイルに保存されているか確認する際の落とし穴
まずは元々の挙動を確認
まずは何も指定もせずにファイルに保存するとどうなるのか確認してみます。
say_nice.rb
File.open("nice.txt", "w") do |f| f.puts "nice" end
ファイルの文字コードを確認する方法は
$ nkf --guess filename
または$ file --mime filename
なので、
$ nkf --guess nice.txt
で確認すると、
ASCII (LF)
どうやらASCII (LF)
という文字コードで保存されているらしい。
$ file --mime nice.txt
こちらでも確認してみます。
good.txt: text/plain; charset=us-ascii
ふむ。やはりASCIIみたいですね。
それでは、文字コードをcp932に変更します。 ちなみにcp932というのはShift-JISみたいなやつです。若干違うけどほぼ一緒みたいな認識を勝手にしてます。
say_nice.rb
File.open("nice.txt", "w:cp932") do |f| f.puts "nice" end
これで文字コードはcp932になっているはずですね、確認してみましょう。
$ nkf --guess nice.txt
ASCII (LF)
ファッ!? 変わってないやんけ!
念のためこちらでも確認。
$ file --mime nice.txt
good.txt: text/plain; charset=us-ascii
おっかしいなー。
思い通りの文字コードで保存されない理由
思い通りの文字コードで保存されない理由は、アルファベットしかないから。です。
上記のコードたちだとアルファベットしか出力してないから、文字コードを判断するに足る情報が少なかったからです。
文字コードというのはhtmlファイルのhead情報みたいにファイルのどこかに保存されているのかなと、勝手に思ってましたが、ファイルの中身を見て判断しているみたいですね。
テキストファイルの文字コードは中身で決まる。らしい。 - Qiita
こちら参考にさせていただきました。
つまり、nice
だけだと、asciiもutf-8もcp932も同じ文字コードで表現できてしまう。ってこと!か
というわけで、再度確認してみる
再度元々の挙動を確認
日本語文字に変更して、
say_nice.rb
File.open("nice.txt", "w") do |f| f.puts "いいね" end
$ nkf --guess nice.txt
UTF-8 (LF)
$ file --mime nice.txt
good.txt: text/plain; charset=utf-8
日本語文字を含めると、UTF-8で保存されているみたいですね。
いよいよ本題、cp932で保存したい。
File.open("nice.txt", "w:cp932") do |f| f.puts "いいね" end
確認してみる。
$ nkf --guess nice.txt
Shift_JIS (LF)
えぇ〜・・・
こちらも
$ file --mime nice.txt
good.txt: text/plain; charset=unknown-8bit
こっちに至ってはunknown言われてるやん。。。
cp932じゃなく、Shift_JISと解釈される問題
$ file --mime nice.txt
の方はさておき、Shift_JIS (LF)
と判別されるのは、同じく、cp932
とShift_JIS (LF)
を判別する文字がなかったためでした。
cp932にあって、Shift_JISにないものを文字に入れて検証。
①
を追加。
File.open("nice.txt", "w:cp932") do |f| f.puts "いいね①" end
これで
$ nkf --guess nice.txt
CP932 (LF)
よっしゃ!
こちらは?
$ file --mime nice.txt
good.txt: text/plain; charset=unknown-8bit
unknownのまま。
もうfile --mime
のことなんか知らないっ
あとで調べてみるか・・・
cp932で保存はできてるんだもんな。
NotebookアプリQuiverのスタイルをCSSでいい感じに変更する。
エンジニア御用達のメモアプリ、Quiver。
オンラインで同期できないことを除けば、今の自分にとって最高のツールです。
メモを見る上で、見やすさはとても重要ですね〜
ということで、QuiverのCSSを変更して、使いやすくしたい。
というか、自分で考えたこのStyleよくない〜?ってのを言いたいだけ (どっかのサイトをベースにしたけど忘れてしまった)
StyleのCSSを設定
Preferance > Styles > Preview
で、CSSを書いていくだけ。
こんな感じでCSSを書き込んでいく。
僕の設定したCSSだとこんな感じになります。
割りと気に入ってます。 CSSのコードは以下です。
body, .editor { font-family: 'Hiragino Kaku Gothic Pro', arial, helvetica, sans-serif; } h1 { border: solid 1px #F89174; border-top: solid 5px #F89174; border-radius: 2px; padding: 5px 5px; color: #000; background-color: #f4f5fb; line-height: 1.3em; font-size: 30px; } h2 { border-left: solid 5px #F89174; border-bottom: solid 3px #DADADA; padding: 10px 10px; color: #333333; background-color: #f4f5fb; line-height: 1.3em; font-size: 22px; } h3 { border-bottom: solid 2px #F89174; padding: 10px 10px; } h4 { border-left: solid 3px #F89174; padding: 3px 8px; }
ちなみに最初の方しばらくはずっとこれを拝借していた。
Quiverのスタイルを変える – IT Nerd Diary
ありがとうございました
ターミナルはFinderやエディタから削除したフォルダを参照し続けてしまう。
$ mkdir dev-trash
$ cd dev-trash
でdev-trash
をルートとして考えてみる。
ルート直下にfoo
ディレクトリと、以下のファイルhello_generator.rb
を作る
file = File.open("foo/generated_hello.txt", "w") file.puts "hello"
このファイルを実行すると、foo
の下にgenerated_hello.txt
ファイルを生成する。
$ ruby hello_generator.rb
ここで、新しいターミナル2を開いて、generated_hello.txt
を確認してみる。
$ cd dev-trash/foo
$ cat generated_hello.txt
すると、以下のようになる。
hello
ここで、Finderもしくはエディタからfoo
を削除する
foo
は削除したにも関わらず、
$ cat generated_hello.txt
とすると、
hello
が表示される。
次にhello_generator.rb
の内容を変更する。
file = File.open("foo/generated_hello.txt", "w") file.puts "goodbye"
そして実行。
$ ruby hello_generator.rb
ターミナル2から、generated_hello.txt
の内容を確認してみると、
goodbye
になっているはずだが・・・
実際は
hello
のまま。
ファイルのハッシュを調べてみる。
ターミナル2にて。
$ md5 generated_hello.txt
MD5 (generated_hello.txt) = c157a79031e1c40f85931829bc5fc552
ターミナル1からも確認する
$ md5 generated_hello.txt
MD5 (generated_hello.txt) = d92a12b93565fce571081b028e361e01
どうやら、ターミナル1とターミナル2が指している同じパスのファイルは、別のもののようだ。
実際、ターミナル1から確認すると、
$ cat generated_hello.txt
goodbye
と正常に生成されている。
つまり、ターミナル2から参照しているファイルは、生成されたファイルとは別のファイルということになる。
$ pwd
などで調べてみても、パスは同じなので同じファイルじゃないのー!?と困惑したけど、どうやらパスというのは絶対的なものではないらしい。
これはターミナル2がゴミ箱に移動したファイル(フォルダ)を参照し続けていたことが原因だった。
ちなみに、ターミナル2から
$ cd ../foo
$ cat generated_hello.txt
とすると、
goodbye
と正常なファイルが参照し直される。
$ rm
コマンドを使用すると、ゴミ箱に行かずに削除されるから、そもそも参照ができないので、ファイルがなければエラー、あれば新しいファイルが自動的に参照されるみたいだ。
flexboxの基本(縦並び、横並び、中央寄せ、左寄せ、右寄せ)
xflexbox、便利です。
何もしないと、以下のように、block要素は縦に並ぶ
See the Pen JWerRv by benzenetarou@gmail.com (@benzenetarou) on CodePen.
親要素にdisplay: flex
を設定すると、子要素が横に並ぶ
See the Pen WpYZRw by benzenetarou@gmail.com (@benzenetarou) on CodePen.
flex-direction: column
を設定すると、再び縦に並ぶ
See the Pen XMyepz by benzenetarou@gmail.com (@benzenetarou) on CodePen.
flex-direction: row
にして、横に並べてから、justify-content: flex-end
を設定すると、右側に詰める。
See the Pen QpJqvE by benzenetarou@gmail.com (@benzenetarou) on CodePen.
justify-content: center
で中央寄せになる。
See the Pen qrQPPJ by benzenetarou@gmail.com (@benzenetarou) on CodePen.
flex-direction: column
でコンテンツを縦に配置してからjustify-content: center
にしても縦並びで中央寄せにはなりません。
jusitify-content: center
はあくまでも、横並びのときに横並びの要素をどう配置するかに使うみたいですね。
縦並びで、中央寄せにしたいときは、flex-direction: column
とalign-items: center
を設定します
See the Pen ryQGvJ by benzenetarou@gmail.com (@benzenetarou) on CodePen.
子要素のうち一つだけ、左寄せにしたいときは、子要素でmargin-right: auto
を設定すると、左側に飛んでいきます。
See the Pen ZemXjv by benzenetarou@gmail.com (@benzenetarou) on CodePen.
flexboxの適用範囲は、display:flex
をしていした要素の子要素までです。
なので、孫要素でもいろいろ位置を指定したかったら、子要素にもdisplay:flex
を設定する必要があります。
See the Pen zZMEXJ by benzenetarou@gmail.com (@benzenetarou) on CodePen.
いろいろ複雑な配置もできる
See the Pen YZRrmz by benzenetarou@gmail.com (@benzenetarou) on CodePen.
【書評】「はじめよう!プロセス設計」マーケティング的思想の片鱗を見た気がする
自社サービスのフローを再度考えてみるにあたって、一度もっと根幹から考え直してみようと思い、手に取った本。
- 作者: 羽生章洋
- 出版社/メーカー: 技術評論社
- 発売日: 2016/11/22
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
[読了時間2時間程度]
結論、いい本だったと思う。
学び
この本からの学びは、以下
ビジネス・サービスは、顧客の課題を解決するためにあるもの。
プロセスの可視化をすることが重要。
誰が、(誰に、)何をして、何が出来上がるのかという暗黙知を可視化して認識する。
プロセス中の例外は、個別に対応せずに、ある程度でまとめて「◯◯時の例外」として処理することで、フローをわかりやすくする
ゴールを明確にする(ゴール・ビジョン・要件の3点を設定)
ゴールに向けて、顧客・支援者・ITという3本のプロセスラインで問題解決を図る。
ユーザーストーリーを描く
といったところを今後仕事に活かしていきたい。
具体的なアクション
具体的には、
新サービスのサービスモデルでは、顧客側のストーリーそしてユーザー側のストーリーの両方を描き、それを解決するためおモデルを構築する。(これはIT以前の問題)
この点に関しては、個人プロジェクトの方でも活かしていきたい。オナニーにならないようなプロダクトを作っていかなければならない。
例外フローは入れ子にすることで、全体の把握を速やかにできるようにする。
これも新しいモデルに関してのことだが、フローを考えるときに、個別の例外やケースに対して、「スコープをどこに設定するか」という視点を持ち、適度な範囲でまとめていく必要がある。
現状では、机上の空論、理論ばかりを詰め込んでも頭でっかちになってしまう状態だから、実際の現場でのケースを体験することから始めていく。
【書評】「コーディングを支える技術」で言語に対する興味を掻き立てられた。
コーディングを支える技術を読んだ。
コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)
- 作者: 西尾泰和
- 出版社/メーカー: 技術評論社
- 発売日: 2013/04/24
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (35件) を見る
今までで、Java、Ruby、python、html、CSS、JavaScriptなどを簡単に触れてきたが、プログラミング言語の本質的なところにはあまり触れてこなかったのだなぁとこの本を読んで思った。
ちょうどこの本を読んでいるときに、YouTubeでRubyの父まつもとゆきひろ氏のN高校での講義の動画があったので見てみた。
プログラミング言語を開発しちゃうくらいだから、物心ついた頃からさぞかしプログラミングっ子だったんだろうなと思っていたが、実はそうでもない。
確か高校生くらいからプログラミングをやりだしたらしい。
それに、そんなに高度なことをやっていたわけでもなく、コンパイラを自作しようとしたら難しすぎて諦めたという話は親近感を覚える。
しかし、そんな状態からいまのMatzがあるわけである。
そんなわけで、ちょっと言語に対する興味が湧いてきていた時期に、ちょうどこの本を読んでみた。
コンピュータの歴史、プログラミングの歴史とともに、なぜそんな文法や決まり、仕様ができたのかをわかりやすく解説してくれている。
これは個人的にコンピューターサイエンスっぽい感じがする、大学でもちょっとアセンブラ言語っぽいverilog(本当はハードウェア記述言語)というものをやっていたので、親近感が湧いて、ちょっと勉強する気になった。
大学時代には「何だこの言語、参考書籍も全然ないし、こんなにプログラム書いてただの繰り上がりありの足し算しかできないのかよ、ゴミかよ」って思っていたが、今になってそれが帰ってきたように思う。 コンピューターって本当はこうやって動くんだということがようやく山の両方から掘っていたトンネルが繋がったみたいだ。
全体を通して言えることは、「プログラミング言語は完璧ではない」ということだ。
コンピューターの仕組みは、ある程度は完璧と言ってもいいものなのかもしれない。 (例えば2+2はいつでも4である。)
しかし、そのコンピューターを使って、人間が作るものはどうも完璧というのはなし得ないようだ。
だからいろいろなルールを作って、なるべく間違えがないようにするにはどうしたらいいだろう?という理念の基プログラミング言語が構築されているのだ。
「正しく書けば、動くんだ」という無機質なものから、「どうすればみんなの考えを理解できるか、自分の考えを理解させられるか」ということを考えていかないと、プログラミング、及びチーム開発はできないのではないか?とひしひしと感じた。
ルール通りに厳格に決めきってしまうのも一方では重要であるが、なぜそれを使っているのかという大本を考えてみると、納得がいくものも多いような気がする。
Web開発でJavaを使っている新卒が「なぜJavaでつくるのか」を読んでみて
なぜシリーズが好きだ。
Javaでなぜつくるのか 知っておきたいJavaプログラミングの基礎知識
- 作者: 米持幸寿
- 出版社/メーカー: 日経BP社
- 発売日: 2005/03/31
- メディア: 単行本
- 購入: 2人 クリック: 24回
- この商品を含むブログ (40件) を見る
背景
Web系でJavaを使っているというと、大抵の勉強会では驚かれる。
主流はruby, phpあたりだろう。 自分でも、なんでJavaなんてやっているんだ…
そう思う。 一度、Javaと言うものをしっかり理解してみようと思い、この本を手にした。。
Javaが出現するまでのコンピューターの変遷を簡単に知ることが出来た。
コンピューター黎明期では、色んなメーカーが自社製品だけにしかない機能を作りまくって競争していたため、 専用のハードウェアでしか動かないソフトウェアが量産されてしまった。 これでは生産性が下がってしょうがない。やってられない。
何をするにせよ、僕たちが最終的に機械に何かをやらせようと思ったらバイナリーデータにしなくてはいけない。 このことは知っていた。
そしてその前段階に、アセンブラ言語と言うものがある。 機械語を直接技術するのではなく、命令語でプログラムを書くもの。 しかし、これも個々のプロセッサに依存する。
そこで生まれたのが、コンパイラ及びコンパイラ言語だ。 C言語、COBOLなどがそれだ。
C言語で書いたコードはコンパイラによって、アセンブリ言語に変換される。 当然これはプロセッサに依存する実行ファイルが吐き出されるので、プロセッサごとにコンパイラが違ってくる。
そうしてできた実行ファイルはそれぞれのハードウェア上で動作する。
しかし、逆に言えば、それぞれのハードウェアでコンパイルしなくてはならない。 これが一般人にはちと難しいと来たもんだ。
そうして次に出来たのはインタープリタ。 これはハードウェアを介さずに、ソースコードを逐次解釈して実行するプログラム。 これにより、コンパイルが不要になった。 しかし、問題点が2つ。 ソースコードが丸見えという点と、実行速度が遅く、できることも限られているという点。(ハードをあまり動かせないから)
これを解決するべく開発されたのが、Javaなのだ!!!!!
Javaはそれぞれのハードウェア、OSの上に仮想的なOS(JVM Java Virtual Machine)を作ることで、環境による動作の違いを吸収している。
その代わり、その特定のハードやOSにしかない高機能なものは、あえて捨てている。 そして得たものは繁用性。
こんなところがプログラミング言語の簡単な歴史と対応させたJavaの位置付けらしい。
Javaのオブジェクト志向について
その後にも、色々説明をしていて、特にJavaのオブジェクト指向についての説明をしてくれていた。 他の本でもオブジェクト指向の本はいくつか読んできたが、どうもオブジェクト指向のありがたみを未だに感じることができない。
この本で得た一連のプログラミング言語の歴史と合わせて考えて、そもそものオブジェクト指向じゃない言語を簡単にでも理解して、その非オブジェクト指向な仕様を体験してはじめて「うわーこれ面倒くさっ」どうにかなんないかな…?
↓
オブジェクト指向の登場
なにこれ便利すぎぃ!!
ってなるのが本筋な気がする。
非オブジェクト指向言語を知らずしてオブジェクト指向言語の良さを語ることは、カレーしか食べたことないのに、カレーの良さを語るのと同様だ。
新卒エンジニアの中期目標としてはいろんな言語を比較しながら、その長短を理解していきたい