やったもん勝ち

主にプログラミングのこと。生産性向上の某とかも。

ターミナルは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: columnalign-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.

【書評】「はじめよう!プロセス設計」マーケティング的思想の片鱗を見た気がする

自社サービスのフローを再度考えてみるにあたって、一度もっと根幹から考え直してみようと思い、手に取った本。

はじめよう! プロセス設計 ~要件定義のその前に

はじめよう! プロセス設計 ~要件定義のその前に

[読了時間2時間程度]

結論、いい本だったと思う。

学び

この本からの学びは、以下

  • ビジネス・サービスは、顧客の課題を解決するためにあるもの。

  • プロセスの可視化をすることが重要。

  • 誰が、(誰に、)何をして、何が出来上がるのかという暗黙知を可視化して認識する。

  • プロセス中の例外は、個別に対応せずに、ある程度でまとめて「◯◯時の例外」として処理することで、フローをわかりやすくする

  • ゴールを明確にする(ゴール・ビジョン・要件の3点を設定)

  • ゴールに向けて、顧客・支援者・ITという3本のプロセスラインで問題解決を図る。

  • ユーザーストーリーを描く

といったところを今後仕事に活かしていきたい。

具体的なアクション

具体的には、
新サービスのサービスモデルでは、顧客側のストーリーそしてユーザー側のストーリーの両方を描き、それを解決するためおモデルを構築する。(これはIT以前の問題)
この点に関しては、個人プロジェクトの方でも活かしていきたい。オナニーにならないようなプロダクトを作っていかなければならない。

例外フローは入れ子にすることで、全体の把握を速やかにできるようにする。
これも新しいモデルに関してのことだが、フローを考えるときに、個別の例外やケースに対して、「スコープをどこに設定するか」という視点を持ち、適度な範囲でまとめていく必要がある。

現状では、机上の空論、理論ばかりを詰め込んでも頭でっかちになってしまう状態だから、実際の現場でのケースを体験することから始めていく。

【書評】「コーディングを支える技術」で言語に対する興味を掻き立てられた。

コーディングを支える技術を読んだ。

今までで、JavaRubypython、html、CSSJavaScriptなどを簡単に触れてきたが、プログラミング言語の本質的なところにはあまり触れてこなかったのだなぁとこの本を読んで思った。
ちょうどこの本を読んでいるときに、YouTubeRubyの父まつもとゆきひろ氏のN高校での講義の動画があったので見てみた。

www.youtube.com

プログラミング言語を開発しちゃうくらいだから、物心ついた頃からさぞかしプログラミングっ子だったんだろうなと思っていたが、実はそうでもない。
確か高校生くらいからプログラミングをやりだしたらしい。
それに、そんなに高度なことをやっていたわけでもなく、コンパイラを自作しようとしたら難しすぎて諦めたという話は親近感を覚える。
しかし、そんな状態からいまのMatzがあるわけである。
そんなわけで、ちょっと言語に対する興味が湧いてきていた時期に、ちょうどこの本を読んでみた。 コンピュータの歴史、プログラミングの歴史とともに、なぜそんな文法や決まり、仕様ができたのかをわかりやすく解説してくれている。

これは個人的にコンピューターサイエンスっぽい感じがする、大学でもちょっとアセンブラ言語っぽいverilog(本当はハードウェア記述言語)というものをやっていたので、親近感が湧いて、ちょっと勉強する気になった。

大学時代には「何だこの言語、参考書籍も全然ないし、こんなにプログラム書いてただの繰り上がりありの足し算しかできないのかよ、ゴミかよ」って思っていたが、今になってそれが帰ってきたように思う。   コンピューターって本当はこうやって動くんだということがようやく山の両方から掘っていたトンネルが繋がったみたいだ。

全体を通して言えることは、「プログラミング言語は完璧ではない」ということだ。   コンピューターの仕組みは、ある程度は完璧と言ってもいいものなのかもしれない。 (例えば2+2はいつでも4である。)
しかし、そのコンピューターを使って、人間が作るものはどうも完璧というのはなし得ないようだ。

だからいろいろなルールを作って、なるべく間違えがないようにするにはどうしたらいいだろう?という理念の基プログラミング言語が構築されているのだ。

「正しく書けば、動くんだ」という無機質なものから、「どうすればみんなの考えを理解できるか、自分の考えを理解させられるか」ということを考えていかないと、プログラミング、及びチーム開発はできないのではないか?とひしひしと感じた。
ルール通りに厳格に決めきってしまうのも一方では重要であるが、なぜそれを使っているのかという大本を考えてみると、納得がいくものも多いような気がする。

Web開発でJavaを使っている新卒が「なぜJavaでつくるのか」を読んでみて

なぜシリーズが好きだ。

Javaでなぜつくるのか  知っておきたいJavaプログラミングの基礎知識

Javaでなぜつくるのか 知っておきたいJavaプログラミングの基礎知識

背景

Web系でJavaを使っているというと、大抵の勉強会では驚かれる。

主流はruby, phpあたりだろう。 自分でも、なんでJavaなんてやっているんだ…

そう思う。 一度、Javaと言うものをしっかり理解してみようと思い、この本を手にした。。

Javaが出現するまでのコンピューターの変遷を簡単に知ることが出来た。

コンピューター黎明期では、色んなメーカーが自社製品だけにしかない機能を作りまくって競争していたため、 専用のハードウェアでしか動かないソフトウェアが量産されてしまった。 これでは生産性が下がってしょうがない。やってられない。

何をするにせよ、僕たちが最終的に機械に何かをやらせようと思ったらバイナリーデータにしなくてはいけない。 このことは知っていた。

そしてその前段階に、アセンブラ言語と言うものがある。 機械語を直接技術するのではなく、命令語でプログラムを書くもの。 しかし、これも個々のプロセッサに依存する。

そこで生まれたのが、コンパイラ及びコンパイラ言語だ。 C言語COBOLなどがそれだ。

C言語で書いたコードはコンパイラによって、アセンブリ言語に変換される。 当然これはプロセッサに依存する実行ファイルが吐き出されるので、プロセッサごとにコンパイラが違ってくる。

そうしてできた実行ファイルはそれぞれのハードウェア上で動作する。

しかし、逆に言えば、それぞれのハードウェアでコンパイルしなくてはならない。 これが一般人にはちと難しいと来たもんだ。

そうして次に出来たのはインタープリタ。 これはハードウェアを介さずに、ソースコードを逐次解釈して実行するプログラム。 これにより、コンパイルが不要になった。 しかし、問題点が2つ。 ソースコードが丸見えという点と、実行速度が遅く、できることも限られているという点。(ハードをあまり動かせないから)

これを解決するべく開発されたのが、Javaなのだ!!!!!

Javaはそれぞれのハードウェア、OSの上に仮想的なOS(JVM Java Virtual Machine)を作ることで、環境による動作の違いを吸収している。

その代わり、その特定のハードやOSにしかない高機能なものは、あえて捨てている。 そして得たものは繁用性。

こんなところがプログラミング言語の簡単な歴史と対応させたJavaの位置付けらしい。

Javaのオブジェクト志向について

その後にも、色々説明をしていて、特にJavaオブジェクト指向についての説明をしてくれていた。 他の本でもオブジェクト指向の本はいくつか読んできたが、どうもオブジェクト指向のありがたみを未だに感じることができない。

この本で得た一連のプログラミング言語の歴史と合わせて考えて、そもそものオブジェクト指向じゃない言語を簡単にでも理解して、その非オブジェクト指向な仕様を体験してはじめて「うわーこれ面倒くさっ」どうにかなんないかな…?

オブジェクト指向の登場

なにこれ便利すぎぃ!!

ってなるのが本筋な気がする。

オブジェクト指向言語を知らずしてオブジェクト指向言語の良さを語ることは、カレーしか食べたことないのに、カレーの良さを語るのと同様だ。

新卒エンジニアの中期目標としてはいろんな言語を比較しながら、その長短を理解していきたい

validetta.jsがieでのみ有効化出来ないバグの解消

ずっとmacで開発していて、一応Internet ExplorerSleipnirでチェックしていたつもりで、ちゃんと動いていたのですが、 やっぱり本物で確認してみると。。。バリデーションが効かない。。。 ieSleipnirは同じエンジンを使っているらしいから大丈夫だろうという謎の慢心でした。。。 危なかった。

バリデーションにはvalidetta.jsを使用しました。

こちらです。 coliss.com

解消法は

F12でデバッグモードを開く

consoleを見てみると、

validetta.jsに関して、

「strictモードでは、プロパティの複数定義は許可されません。」

見てみると、たしかにvalidetta.jsの中に

“use strict”; の一文が・・・

これを削除。

どうだっ!?

いけました。

MacOSで既存のplay frameworkのプロジェクトを実行する環境構築をする

MacOS Siera Ver.10.12.2 おにゅーのMacでplay frameworkの環境設定を行いました。 プロジェクトは既にあったので、そこら辺は別のサイトの情報を参照ください。

Javaのインストール

まずは、Javaのインストール

$ Java -version

でinstallされているか確認する。

installされていなかったら、installページに飛べるダイアログが出現するので、クリック。

http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.htmlmacOSのDownloadファイルをダウンロード、展開

順番に進めていくと、ブラウザで確認画面になる。(Chromeだと確認できないみたいなので、デフォルトブラウザをサファリにしておく)

ブラウザでも確認できるが、(よくわからなかった) Macの左上りんごアイコンから、システム環境設定>Javaコントロールパネルで確認。

てかMacは標準でインストールされているのですね・・・

play frameworkのインストール

続いて、play frameworkのインストール

基本的には公式ドキュメントに書いてあります。 sbtがなければインストールするとのこと(sbtとはscala用のbuildツール)

$ brew install tbt

エラー:javaがないとのこと。 ???

javaはあるはずなのに… エラーログでbrewでinstallせよと言っていたので、従う。

brewjavaを再インストール

$ brew cask install java

sbt new playframework/play-java-seed.g8

コマンド。 activatorをinstallする

適当なディレクトリで展開して、activatorのパスを通す。

$ sudo atom .bash_profile

環境変数を設定する。(もちろんatomじゃなくてもなんのエディタでもいい)

activatorが~/developに展開したので、

export PATH=/Users/yoshii/develop/activator-dist-1.3.12/bin/:$PATH

を追加する。

$ source ~/.bash_profile

をしないと、パスが通らない。(更新されない)

echo $PAHT

でパスが通っているかを確認。

アプリケーションが既にあるなら、そのディレクトリに移動し、

$ activator

[play] run

これで実行できました。