本に書いてある通りやっても何故かバリデーションが通らない。

何度やっても「Password Missing password」と怒られるばかり。
物は試しとGoogleで似たような人がいないか検索してみるが それらしいものは見当たらない。

試しにModelを全コピするが一向に改善しないため、どうやらtypoではないようだ。
( 元々3.2系の本だから ちょいちょい仕様が変わってたりするんだよなあ…今回もその周りのにおいがプンプンする )

それでもって POST時にユーザから渡って来たログを出してみて、その値を確認してみた。

Parameters: {"utf8"=>"V", "authenticity_token"=>"c4yT/Bt6ypoDW5rl119tndpOZgLLAE4pv824XPZXRdM=", "user"=>{"name"=>"aef", "password"=>"[FILTERED]", "password_confirmation"=>"[FILTERED]"}, "commit"=>"Create User"}
Unpermitted parameters: password, password_confirmation
==========================================
Unpermitted parameters: password, password_confirmation
{"name"=>"aef"}
=========================================

password と password_confirm が入っていない。それでもって、その上に何やらおかしなエラーが。
「Unpermitted parameters: password, password_confirmation」

というわけで「Unpermitted parameters」で検索をかけた所、原因が判明。

Rails4系から Strong Parameters というのが導入されたらしい。
どうやら ホワイトリストみたいな感じで、「このパラメータ以外は受け付けないよ」というのを generate scaffold する際にコントローラに自動で記載してくれるらしい。
そこでusers_controllerを見てみると…。

# Never trust parameters from the scary internet, only allow the white list through.
def user_params
  params.require(:user).permit(:name, :password_digest)
end

あったあった。フロント側で仮想的にパラメータを立てる際はここも変えないとダメだったみたい。
というわけで以下のように変更。

# Never trust parameters from the scary internet, only allow the white list through.
def user_params
  params.require(:user).permit(:name, :password, :password_confirmation)
end

今度は無事に通った。

The post 【RailsによるアジャイルWebアプリケーション開発第4版】イテレーションI1 Rails4系 ログイン周りのバリデーションでハマった話 appeared first on きのこる庭.

ここ最近 せっかくプログラミング言語の作り方を勉強している最中だし、どうにか二郎のコール(いわゆる二郎語の一部)をプログラミング言語で再現できないだろうかと頭を悩ませていたが、最近ようやく ある程度形になってきたのでシェアする。

(正直な所、タイトルは「プログラミング言語」になっているものの、「やってる事ただのコンパイルじゃねーか」という感じになっちゃってます。 極めつけに「yaccとlex使ってるだけじゃねーか」って声が聞こえてきそうですが、どうか許してください )

test.jiroファイルの用意

以下は「二郎語」で書かれたファイル「test.jiro」である。「ニンニク入れますか？」を契機に、怒涛のコールが始まる。

「ニンニク入れますか？」「ヤサイニンニクアブラ」「ヌキ」「ヤサイニンニクアブラ」「ニンニク」「ニンニクアブラ」「ヤサイカラメ」「ニンニクアブラ」「ニンニクアブラカラメ」「ヤサイニンニクアブラ」「アブラ」「ニンニクアブラ」「ニンニクアブラ」「ニンニク」「カラメ」「ニンニク」「ニンニク」「アブラ」「カラメ」「ニンニクアブラ」「ヤサイアブラ」「ニンニクアブラ」「アブラカラメ」「ニンニクアブラ」「アブラカラメ」「ニンニクアブラ」「全マシ」「ニンニク」「ヌキ」「ヤサイアブラ」「ヤサイニンニクアブラ」「ニンニクアブラ」「全マシ」「ヤサイニンニクアブラ」「ニンニク」「ニンニクアブラ」「アブラカラメ」「ニンニクアブラ」「アブラ」「ニンニク」「ニンニク」「ニンニク」「ヤサイカラメ」「ヤサイニンニク」「ヤサイニンニクカラメ」

ソースコード(コール)内容:  「ニンニク入れますか？」「ヤサイニンニクアブラ」「ヌキ」「ヤサイニンニクアブラ」「ニンニク」「ニンニクアブラ」「ヤサイカラメ」「ニンニクアブラ」「ニンニクアブラカラメ」「ヤサイニンニクアブラ」「アブラ」「ニンニクアブラ」「ニンニクアブラ」「ニンニク」「カラメ」「ニンニク」「ニンニク」「アブラ」「カラメ」「ニンニクアブラ」「ヤサイアブラ」「ニンニクアブラ」「アブラカラメ」「ニンニクアブラ」「アブラカラメ」「ニンニクアブラ」「全マシ」「ニンニク」「ヌキ」「ヤサイアブラ」「ヤサイニンニクアブラ」「ニンニクアブラ」「全マシ」「ヤサイニンニクアブラ」「ニンニク」「ニンニクアブラ」「アブラカラメ」「ニンニクアブラ」「アブラ」「ニンニク」「ニンニク」「ニンニク」「ヤサイカラメ」「ヤサイニンニク」「ヤサイニンニクカラメ」

コンパイル

前述の二郎語によって記述されたコールをコンパイルするために、linux上で以下のようにコマンドを実行する。

./jiroparse test.jiro

すると、以下のように二郎語で書かれたコード(コール)をベースに「jiro.c」というC言語のファイルが出力される。

この中身を見てみると、二郎語によるコールがC言語に正常にコンパイルされてHello world が出力されていることがわかる( int main(void){ …、 return 0; } あたりの処理は割愛しております)。

printf("Hello World");

どういうことなの？

結局の所、データというのは バイナリの集まりである。
例えば、hello という文字列は 16進数で言う所の「68656c6c6f」である。この16進数文字列を分解すると「68」「65」「6c」「6c」「6f」となる。つまり、16進表現のセットさえつくることができれば良いわけなので、それぞれの二郎語によるコールについて、

・「ヌキ」…0
・「ヤサイ」… 1
・「ニンニク」…2
・「アブラ」…4
・「カラメ」…8

として割り当て、これらを組み合わせることによって成立する16進表現の2セット(=二郎語でのコール2回分)を「1文字」としてコンパイルする。

二郎語における16進表現 0～16、255の例

0 … 「ヌキ」「ヌキ」
1 … 「ヌキ」「ヤサイ」
2 … 「ヌキ」「ニンニク」
3 … 「ヌキ」「ヤサイニンニク」
4 … 「ヌキ」「アブラ」
5 … 「ヌキ」「ヤサイアブラ」
6 … 「ヌキ」「ニンニクアブラ」
7 … 「ヌキ」「ヤサイニンニクアブラ」
8 … 「ヌキ」「カラメ」
9 … 「ヌキ」「ヤサイカラメ」
10 … 「ヌキ」「ニンニクカラメ」
11 … 「ヌキ」「ヤサイニンニクカラメ」
12 … 「ヌキ」「アブラカラメ」
13 … 「ヌキ」「ヤサイアブラカラメ」
14 … 「ヌキ」「ニンニクアブラカラメ」
15 … 「ヌキ」「ヤサイニンニクアブラカラメ」(または「ヌキ」「全マシ」)
16 … 「ヤサイ」「ヌキ」
255 … 「ヤサイニンニクアブラカラメ」「ヤサイニンニクアブラカラメ」(または「全マシ」「全マシ」)

つまり、上記のセットの形態を取ることにより、たった4種類の二郎語だけで unsigned char が表現可能な0 ～ 255 までの値を全て表現することが可能となる。

例えば 上記に示した二郎語によるコード(コール)のうち、最初に記載されている「ヤサイニンニクアブラ」「ヌキ」という二郎語のコールはそれぞれ16進数で「7」「0」つまり70となり、これはprintfの「p」にあたる。

※ なお、一部のジロリアン、ロティスト、ロットマイスター、ロットマエストロのために糖衣構文として「ヤサイニンニクアブラカラメ」全てが入る場合は「全マシ」コールをサポートしている。

※ 「小ブタ大ブタサポートしてないのは二郎語として失格」って言われそうなので「小ブタ」「大ブタ」「小ブタダブル」「大ブタダブル」「小ブタW」「大ブタW」という二郎語のコールも一応サポートしている( ただし入れても全く意味が無いのでバイトを食うだけ )。

どうしてこんなバカな真似を…

この世の中、バカな真似ほど…狂気の沙汰ほど面白い…

因みに、元々ちゃんとプログラミング言語っぽくしようと思ったものの、二郎のコールや用語はプログラミング言語の文法規則を表現する上で相当ハードルが高く、流石に通常のプログラミング言語の作り方では表現できないと悟ったため上記の形式になった。

因みに brainf**kとかの言語は上のような冗長なことをせずにポインタ操作をすることで実装されているみたい。

Github ( 2014.04.18追記 )

とりあえずGithub上にソースコードを上げてみた。ファイル整理できてない上に誰が見てもまるっきりC言語初心者が書いたようなコードなので恥ずかしいが知ったこっちゃない。

jiro-programming-language

それにしても人生で初めて上げたGithubのプロジェクトが二郎というのも複雑な心境。

そのまた後日 ( 2014.04.21追記 )

新代田にある二郎が4月末で一度お店を占めるということなので行ってきた。

当然店に入るとコールが飛び交っているんだけど、脳内で勝手に二郎語がコンパイルされてしまい(「ヤサイニンニクアブラ」が「7」に変換されてしまう)、もはや普通に二郎を食える身体ではなくなってしまった。

以上レポっす。チラシの裏すいません。

The post 二郎はラーメンではなく二郎というプログラミング言語である – 二郎語ではじめるプログラミング入門 appeared first on きのこる庭.

上記の構文規則に基づくとすると、
10 + 20 * 5 + 10 * (1 + 1)
の再帰ルーチンは以下のようになる。
(なお、 expression(), term(), factor() はそれぞれ上記の構文規則を実装した関数 )

簡単な解説

再帰的下向き構文解析って？

コンパイラとかで構文を解析する時に使う方法の一つ。

例えば以下の図は再帰的下向き構文解析を行うための簡単な規則の例です。

ここで使用しているそれぞれのワードについては以下の式を考えると分かりやすいかもしれないです。

10y + 3/5(10 + 10)

数学では 10y とか 3/5 とかのことを「項(term)」と呼ぶけど、
10y, 3/5 というのは
複数の変数・数値を割って成り立っているものなので、

10y = 10 * y
3/5 = 3 / 5 * (10 + 10)

というように、
項は 複数個の 割り算 または かけ算 によって成り立つ一つの単位として考えられるので、上記のような構文規則になります。

この項を足したり引いたりしたものをここでは「式(expression)」と呼びます。

10y + 3/5(10 + 10) は式です。

「あれ？そうすると ( 10 + 10 ) は式じゃないの？」
となりますが、こちらの 10 + 10 も立派な式です。
ですが、最初の expression() の段階では計算しません。
項を更に分割した単位である「因子(factor)」まで分解して 因子にたどり着いた段階ではじめて 式に変換して計算を開始します。

因子については、上の式で言うと

10, y, 3, 5, (10 + 10) にあたります。

10, y, 3, 5 はそれ以上分解できない「定数」「識別子」としてそのまま処理され、
括弧がついている場合は「その中に式がある」と判断して計算を開始します。

The post [Cコンパイラことはじめ] 再帰的下向き構文解析の再帰ルーチンがいまいちイメージできない人に送る記事 appeared first on きのこる庭.

週末でC言語のポインタ本読了してました。
Web系にいるものの、最近こういう低級言語に触れ合っているとなんとも言えない楽しさを感じるので 会社が終わるとそっちの方ばっかりいじってます。

ところで、ここ数日は色々と細かいタスクが増えてきたので 自分用に簡単なGTDのツールをつくろうとLINQまわりをいじっていました。
今回はXMLの保存・読み込みということで記事投稿。

準備

using System.Xml.Linq;　// XDocument オブジェクトを使用する。
using System.IO; // ファイルの保存・読み出し時に必要。

とりあえずアセンブリ参照の追加。

XMLをつくってみる。

XDocument F = new XDocument();
F.Add(new XElement("RootNode")); // ノードの追加
F.Save(FileName);

これで FileName に指定したパス・ファイル名でxmlデータが保存される。
今回はこんな感じ。

<?xml version="1.0" encoding="utf-8"?>
<todolist />

※ XMLにルート要素の追加をせずに保存すると読み出しの際にランタイムエラー吐くので注意。

ちょっといじってみた感じ、よくあるXML操作関連のAPIのような操作性で直感的に操作できて良い感じ。

つくったXMLを読み出してみる。

せっかく保存しても読み込みができないとさびしいので、読み込んでみる。

XDocument F = new XDocument();
if(File.Exists(FileName)){
    F.Load(FileName);
}

てな感じで 保存したXMLドキュメントの読み込みができる。

でも一つのXMLファイルに大量のノードファイル詰め込んだらパフォーマンス落ちるんじゃないの？
と思って50,000ノードほど単純な文章を連ねたXMLファイル(約24MB)を追加してデバッグしてみたけど、
読み込みが描画処理含めて 250ミリ秒 とかなので、日頃使う簡単なツールの実用には困らないレベル。

( 因みに その時は

<Root>
  <createdDateTime>~~~~~~~</createdDateTime>
  <description>はじめてのしーしゃーぷでりんくをためしてみるよ</description>
</Root>
 ：
 ：

という感じの、深さが全く無いノード構成だったからスピードが出ていた可能性も。
ノードが深くなった場合とか複雑化してきた場合は未計測 )

とはいえ、たった一つのXMLファイルに全てのデータを入れて 万が一データ破損でもしたら一発でおしまいだろうから、
ちゃんと作りこむなら定期的にバックアップファイル生成するとか 分散管理とか 別の施策が必要なにおいはする。

(ちょっと寄り道)Configurationを使ってみる

using Configuration; // AppSettingsReader オブジェクトを使用する。

App.configへの追記。
<Configuration> ~ </Configuration> の間に以下のコードを追加。

<appSettings>
<add key="DataFile" value="C:\Users\hoge\Desktop\data.xml" />
</appSettings>

こんな感じで登録しておけば、

string FileName = (string)(AppSettingsReaderインスタンス.GetValue("DataFile", typeof(string)));

こんな感じで参照可能。

The post はじめてのC# (3) – LINQを使用してXMLファイルの保存/読み込みを試してみた appeared first on きのこる庭.

ブログを更新していないしばらくの間、WPFをいじくり倒してました。おかげさまで、超簡単なデスクトップアプリケーションならなんとかつくれるようになりました。
というわけで週末は勉強がてらWPFでクッキークリッカーっぽいものをつくって遊んでました。

そこで感じたのが、
複数ウィンドウでデリゲートとかイベントとか書いてるうちにクラス間の関係が密結合になってしまうということ。
こういう場合、一つのクラスの規模が大きくなってきて ある属性をクラス化して分離したくなった時とかになかなか面倒くさいので、
一つメディエータみたいな感じのクラスが欲しい。

でもエントリポイントがWPFの一クラスだとあまり綺麗な構造になりそうもないので、
いっそのことエントリポイントをWPFのクラスじゃなくて通常のC#クラスにしてしまって、WPFを分離してはどうか。
さらに各描画用インスタンスを保持するクラスを用意して、複数ウィンドウ間でのイベント処理を楽にしてはどうかという発想に至った。
(API化すれば良い気もするが)

＊なお、この記事はC#/WPF超初心者が執筆しているので、参考にする場合は十分に注意してください。また、「いやそもそもこうした方が楽じゃね」っていうところに関してはどんどんご指摘いただければ幸いです。

プロセス

1. 「空のプロジェクト」を選択。
2. エントリポイントになるクラスの追加。
3. とりあえずコンストラクタを書いておく。

* ここまでは通常のC#プログラムの作成と同じ。

4. Lib/Display ディレクトリの作成
5. Directory 内に　WPFクラス FrontWindow.xaml / FrontWindow.xaml.cs の作成
6. .NET環境とかだと デフォ値で UserControl になっているので、xaml, xaml.cs ともに 基底クラス云々を Window に差し替え。
7. さらに WPFクラス App.xaml の作成。
8. UserControl → xaml, xaml.cs ともに 基底クラス云々を Application に差し替え。
9. System.xamlのアセンブリ参照が追加されていない場合は追加。
10. Display 内に メディエータとなる DisplayBaseクラス の作成。

11. DisplayBaseクラスに ShowFront() メソッドの追加。

public FrontWindow FW;
public Application App = new Application();

public void ShowFront(){
FW = new FrontWindow();
FW.Show();
App.Run(FW);
}

App.Run(FW) という形にする理由として、
Showメソッド自体そもそもnon-blocking callで、普通に呼び出してもウィンドウがパッと開いて閉じてしまうから。

12. エントリポイントのクラスのコンストラクタの書き換え。

[STAThread]
public static void Main(){
DisplayBase Display = new DisplayBase();
DisplayBase.ShowFront();
}

STAThreadをつける理由として、
WPF自体 STAThread というスレッド以外で動作させられないようになっているので、
通常のエントリポイントからWPFオブジェクトを呼び出してしまうと例外が飛んでしまうから。

13. 毎回立ち上がるコマンドプロンプトを消す。

プロジェクト　> ●●(プロジェクト名)のプロパティで出力の種類「コマンドプロンプト」になっている部分を「Windowsアプリケーション」に選択しなおす。

だん。

アドバイスなどございましたらどしどしご指摘いただければ幸いです！

それではまたm(_ _)m

The post はじめてのC# (2) – 通常のC#クラスをエントリポイントにしてWPFを使用する appeared first on きのこる庭.