Programming Experiments

Initial Release of my web tools

2007-06-20T17:39:00.000-07:00

I placed the Erlang-based web tools that I am working on for the development of some of my own applications online. They are very rough, in that they are a big mix of experimentation and trying to get something working to write some actual applications. So, the documentation is weak, and there are still certain conventions and features that I need to work out that are not particularly complete yet. (So it is version 0.0.1 :)) I am not really concerning myself over making the system polished; what I wrote were just things that I found myself comfortable to work with.

The two tools are (with the most dullest of names):

1. Weberl is a request handler that uses Yaws. The difference between this and ErlyWeb is of its heavy dependence on OTP for configuration, and all that OTP provides and that it uses behaviours for controller modules. It uses SGTE as a templating tool.

2. Formtool is two things: a special form processor for handling basic forms and their validation, as well as a form generator given a specific form layout. (I wrote a draft of an academic paper on this project a month or two ago on this, as a joke. I was going to put that in the archive for this project, but I just got too embarrassed to release it at the last moment. :))

There are other things I wrote that might find their way into the above, but they are not for public consumption now. :)

Links:
Weberl
Formtool

They are both licensed under the BSD license.

If you see anything interesting in this stuff, and have a million questions for me, then you can email me at brian@qinternet.com.

Framework Experiment

2007-05-02T19:38:00.000-07:00

Today I was experimenting with a few ideas for an Erlang web framework.

I wanted to utilize OTP like features more, like using a .app file, making the application a server, writing controllers using the behavior feature. I also want to see where I can use the release handling features, since I depend on the .app file for configuration.

It works, sort of. It ain't complete. The server does not work. But, other than that, right now, it is quite simple.

I am not ready to release it, but I put the [incomplete] docs online for now. It is at [http://www.pushon.org/overview.edoc]. If those see this as something interesting to work with, I'll eventually set up a subversion repository.

Simple Dynamic Record Access, Redux

2007-04-15T19:14:00.000-07:00

I sparked a little interest in my post. I thank everyone who has commented on my post, both the comment on Reddit, and the comments made here. Now on my list of things to do is to read deeper about this topic.

I will admit that I did not make the most spectacular of implementations of the idea (with a max of like 3 minutes actually thinking about it, just to get something working, excluding writing the entry :))

I did think I was a bit hasty in saying 'hate' like in the phrase 'I hate records'. I 'wish' they were more dynamic, but I am not weeping over it, since myself, ayrnieu (http://programming.reddit.com/info/1i147/comments) and Philip Robinson (http://chlorophil.blogspot.com/2007/04/dynamic-record-access-functions-with.html) were able to tackle something over the idea. I knew its limitations, so I have tended to use proplists mostly instead, for small lists. It was when I had to consider trying to do dynamic access, I was saying "ohhhhh!"

Eh, anyway, forgive the non-technical response. I am going to do some cutting-and-pasting later, replacing my own with a better implementation. :D

Simple Dynamic Record Access

2007-04-14T17:24:00.000-07:00

There is one thing I hate about Erlang, and it is records. It is not so much that the syntax is annoying (yet I am getting used to it), but you cannot use that syntax for dynamic field access; records are a compile-time feature.

So, without using Yariv's Smerl for something like this, I opted for a simpler solution. Records are tuples after all, and you can get record information in a list. So, you can use these two facts to create a function to get the field you specify. Not anything stellar, but for dynamic record access, it works:


find(Item, List) ->
 find_(Item, List, 1).
find_(Item, [], _) -> not_found;
find_(Item, [H|T], Count) ->
 case H of
  Item ->
   Count;
  _ ->
   find_(Item, T, Count+1)
 end.

get_rec_value(Key, Rec, RecordInfo) ->
 case find(Key, RecordInfo) of
  not_found ->
   undefined;
  Num ->
   element(Num+1, Rec)
 end.

I couldn't find something like "lists:find/2", so I implemented my own. But the main function is "get_rec_value/3". So you do this:

1> rd(person, {id, name, email}).
2> get_rec_value(name, #person{name="Brian"}, record_info(fields, person)).
"Brian"

For fun, I also did setting record value.


set_rec_value(Key, Value, Rec, RecordInfo) ->
 RecList = tuple_to_list(Rec),
 case find(Key, RecordInfo) of
  not_found ->
   Rec;
  Num ->
   List1 = lists:sublist(RecList, Num),
   List2 = lists:sublist(RecList, Num+2, length(RecList)),
   tuple_to_list(List1 ++ [Value] ++ List2)
 end.

3> set_rec_value(email, "c", #person{name="Brian", id="1", email="b"}, record_info(fields, person)).

I know this stuff looks really simple, but since I thought this was a bit of a nuisance, the fact that I cannot access records without hardcoding the values, something needed to be written.

Did I miss something though? I'd like to know. Please comment. :)

The Case For Erlang For Web Applications

2007-04-11T10:51:00.000-07:00

This is the topic I am working on for a paper for my final-year project. The problem with the topic is that it is seriously general, since it can cover so much, like performance and scalability concerns, development concerns, etc. So, while in the midst of preparing to debate this question, I have sat and asked myself "Is there a case to use Erlang for web applications?"

So I am focusing on two areas: "How well can a single Erlang node (the interpreter + the hardware) handle a significant load?" I will admit that I never deployed any web application that is used by more than at most, 10-20 people. There are a lot of concerns that I might be overlooking when considering scalability and performance aspects, so I might be jumping in this naively. However, I am a bit inspired by this one point: "If Erlang can perform well on a single piece of hardware, then can this make scalability potentially easier?" This reminds me of the things I have been reading about Ruby on Rails and the scalability problems that people have been having with that, even though I keep hearing "Well, if you are getting a a lot more hits than your system can handle, then I think you can afford more hardware." Potentially, but it seems very convenient to say when you have to actually deploy a system because your current server setup cannot handle the load.

So, bandwidth excluded, what if my small setup of Rails servers cannot take a current spike because of some Slashdot effect occurring? Or what if I have my Web2.0ish application, dinky and small as it is, become the talk on people's lips, causing a spike in load? (I think that would be wonderful, though ;) )

The fact is, I don't know what would happen. But, at the same time, I am not denying the efficacy of well-designed setups that are running Rails applications. But I am assuming something: if they say that Erlang can potentially handle a lot of load, very well, and if it was designed with this in mind, with a very practical and complex application in mind, can it not help when running my not-so-complicated, dinky little web site? Okay, I might get 10 hits on it every week, but even if I only getting 10 hits, Erlang is not really a sledgehammer to drive in a finish nail. That's where Java would come in.

The fact is, with a little effort, one will find doing web development in Erlang to be easy. Okay, it is not up to the level of Rails in terms of features. However, even regardless of the performance and scalability features that are in Erlang, it is showing me, incrementally, to be a very simple but very powerful language framework to get things done.

I said in an earlier post that I am finding it easier to debug certain things because there is no indeterminacy in variables. Erlang is also dynamically typed, so it, initially was easy to pick and learn, and apply my existing understanding of recursion and of higher-order functions to this language.

So, what I am trying to stress here is that, I think, for what I know, as compared to what other people have been saying, I think that using Erlang, with a platform that has been proven for the types of things that it was designed to do, along with its ease of programming, can be said to be a good platform for web application development. It might not be *perfect* (like the things people complain about in terms of string handling), but these things do not outweigh the positives.

This, is, of course, all a crazy assumption, still. I still have yet to get my tiny web app running to actually run tests on it.

The thing that I am worried about though is how to say all the stuff I said in the typical dry academic tone that I will be compelled to use for my final paper. Ugh. But one reason I wrote this is to figure out how to do just that. The thing also is that all the assumptions I have made here are still willingly open to skepticism, and I open and willing to challenge those assumptions.

I just hope that anyone who is reading this might not immediately jump to the conclusion that I am nuts or I don't know what I am doing; my daily blog readings on Reddit and other places give off this sense, particularly if the object of debate is an article that seems too sure of itself.

Some Observations

2007-04-07T18:00:00.000-07:00

I have been working on a number of Erlang-based projects this week; it's spring break! Most of them are just simple libraries. I would think that my code is not the greatest, but I did notice a few things.

1. Having variables not change state does help. Coupling that with unit testing, it makes debugging quite straightforward. The fact is, is that when you focus using functional techniques, by that virtue alone, you remove indeterminacy in what values variables are. Imperative programming did tend to make me a sloppier programmer, I think, and for this, I always felt a bit uncomfortable with the type of code I was writing. In Erlang, most errors that I am making are mostly silly pattern matching errors. I will admit, in this regard, just in terms of the variable issue, I feel more confident with the code that I am writing.

2. I faced some challenges when I was dealing with looping over some data structure that seemed perfect for a regular loop. In these cases, given that I forced myself to pose the question in a functional way, the resulting code was more concise in the end.

3. Besides minor problems that would come up, I have been consistently producing semi-complicated functions that work correctly the first time. I have not documented specifically when this has occurred. All I remember is that it happened a number of times and I was pleasantly surprised. It is a pleasant surprise because it never seemed to happen that way when working in an imperative language. In functional programming, with Erlang, there are cases where I consider what the problem is, write a little documentation to describe it, then just write it (I have not committed myself to TDD yet). Thinking functionally gives me a chance to look at the problem on a very high level, like, in terms of how the data structure is structured, the types of transformations that are applied to the structure, and what the results of functions over the data structure are. With those in mind, producing good-working functions tend to be the result.

4. I will admit that I have not worked much concurrency with Erlang. Most of the work I have done has been using sequential Erlang. Concurrency is a little harder, but the times I have actually worked with it were times when I just sat down and coded something, not exactly knowing what I was coding. I wrote a short program that opens a large number of processes and then each process sends a message to each other process. There was some weird things that were occurring with it, but it works, and not being a multi-threading wizard by a long shot, I think this was really really nice.

5. Pattern matching is probably one of the most useful language features next to variables not changing values (of course though, the two ideas are connected, since variables are patterns.) The type of things that I am doing with pattern matching is just utterly amazing; I use it in every program I write. The power lies in how I am able to describe large ideas through simple functions, by a matter of how the particular function accepts its input. In one tool I am writing (the one I mentioned in the prior post), I can easily categorize a cross-section of features for different parts of the execution of the tool using patterns; the approach is concise and is very clear to me. Here is an example:


when_valid(login, Form, Args) ->
 Vals = erlyform_maker:form_values(Form),
 Results = yak:login_user(proplists:get_value(username, Vals),
                                 proplists:get_value(p1, Vals)),
 case Results of
  {error, user_not_found} ->
   {failure, "Username or password was incorrect. Try again."};
  {atomic, SessionId} ->
   yaws_api:setcookie("yak", SessionId}
 end;



when_valid(signup, Form, Args) ->
 Vals = erlyform_maker:form_values(Form),
 Results = yak:create_user(proplists:get_value(username, Vals),
                                  proplists:get_value(p1, Vals)),
 case Results of
  {error, username_already_exists} ->
   {failure, "The username you selected already exists."};
   _ ->
   ok
 end.

In the code above, I handle a case where web form data is valid. I have two such forms in this case, and they are both related to authentication. My tool goes ahead and validates the data that comes in and is able to call the right function above. I can't explain how neat this is. I wish Python had something like this.

(Let me explain a design goal in this. If a user submits a form on the web, it comes to my server and my tool checks to see if the form is valid. If so, it calls the "when_valid" function. If there is no "when_valid" function, it calls a default version. The "when_valid" function just returns data. This is opposed to a normal ErlyWeb controller where you return an ErlyWeb tuple. I separated that out, since I never liked framework-level code to be mixed in such a way with this type of application logic.)

6. Not worrying about OOP has helped me immensely. When I stopped thinking about OOPish things, which is one reason why I started using functional programming more, it has helped me focus on my problems more. There are a number of things that have started to go through my head on this issue. Of course, it is a bit personalized. One of the main issues is that, whenever I am working in an OOP language, I feel obligated to do things in an OOPish way and not in a way that solves the problem most simply, as well as cleanly. This is merely my way of wanting to use the best practices of the language. To me though, the best practices of a given OOP language are not really the best practices to me.

The confirmation of my incremental success that I stated earlier lies in the absence of OOP. Maybe for big enterprise-y stuff it works nice. Maybe it is nice to know what a particular piece of data is, in the context of a software system. Maybe something like data encapsulation on objects really does wonders for ensuring some form of safety of implementation in big software systems. But, for the first, I am not working on enterprise-y stuff. For the second, if I need to say what something is, I put it in a tuple, and document that, for example, the data that is being returned is a tuple that begins with a specific atom. And, for the third, if I need data encapsulation, I always got the support of Erlang's module system.

I could go on what *I* do not need in OOP. This is not the point. I have come to the opinion now if I am worrying myself over side concerns to suit the best practices of a language, maybe I should try another language. This is, at least, for cases where I have complete control over language choice.

I do worry over Erlang standards. I lay out all my projects the OTP way. I try to focus on writing code with the principle of "just let it crash if it fails." But see, these things don't get in my way.

Anyway, I went on too long. So, I'll shush now.

Web Forms With Erlang

2007-03-24T14:03:00.000-07:00

I started a project that I eluded to in my previous entry. I only wrote the specification and started on some code. so it is far from complete. This is what I wrote so far as a "goal" statement:

A mini-framework on top of ErlyWeb to:

1. Generalize a common set of patterns when related to web form development.
2. Siimplify the creation of forms for instant gratification.

This is accomplished by:

1. A general web form behaviour in Erlang, which handles generating new and edit forms as well as deleting and retrieving data for results or details.

2. A specific way of creating multiple amount of forms in a unit.

3. A way to quickly generate forms, which can be played with immediately.

4. An HTML form generator that takes form specificiations an can genereate simple forms as something to start off with before a better design is created.

5. The allowance of the system to easily adapt to new HTML designs and code.

The idea is this: I got a form of something - be it data to fill in from one or more database tables, or email to send, or whatever. The implementation makes a common set of assumptions about what is going to happen to the data.

The assumptions are this:

- This something will be created.
- This something will be edited.
- This something will be deleted.
- This something will be retrieved.

What is being modeled is the common expectations of what will be performed:

- Data needs to be validated
- If validations succeed, we need to know what to do next.
- If the validations fail, we need to know what to do next.

The system will have a sensible set of defaults, making it possible to make a form quickly, with the validations, and the form can immediately be tested (without any database code or what not.) When the form is shown to work, the details can be plugged in. (One idea that came to my head was to have the framework make a temporary table in Mnesia, so the retrieving aspect can be quickly tested.)

My idea is to utilize an Erlang behaviour in this case. With a behaviour, the compiler can check if my specific forms are missing functions, and warn the developer of the missing function.

The result is a framework the mixes a bit of simplicity (sort of what you get with ErlyWeb or Rails instant CRUD generators) as well as being general enough to be actually useful outside of just simple CRUD.

In this process, I have started to rewrite my HTML form builder I mentioned in a prior post. There is a lack of generality in it that I need to fix.

An HTML Form Builder

2007-03-03T18:17:00.000-08:00

Here is a form builder I wrote in Erlang. I had an idea earlier, related to a project that my brother wants me to work on. I thought that it would be fruitful for us to both sit down for a few hours constructing a web site. He does not know how to code, but he can discuss aspects of what I am hacking up, so we can discuss changes while I am coding. I told him that I want to make the process of creating forms quickly, so, in a stroke of inspiration, I threw this little module together.

There is little error checking involved in the code, but then, maybe, given the Erlang guidelines, this is a good thing. Look and see. Maybe you'll find it useful. I am going to update it when I need to.

The code is here. An example form: here. Sample test code: here.

UPDATE: This little sample code makes me extremely happy, because I was able to have a very vague idea of what I wanted, and I was able to translate those ideas into working code in a reasonable amount of time. I think I can attribute this to functional programming and pattern matching. My next step (er, tomorrow :) ) Is to make a web page to generate forms, with interest in accomplishing what I want to do when my brother and I sit down and get some code working for our app.

An Erlang Project

2007-03-03T11:45:00.000-08:00

I figured that I am maintaining a focus on a particular language and am going to progress in a particular project for my computer science degree, I might as well use this space to discuss Erlang more and what I am doing in it.

What I am focusing on, for my final-year project is a study of the use of Erlang in the context of web applications. I am evaluating what interesting things that are in Erlang that can be utilized in the context of web programming. For example, is the language robust enough for general web programming? Or, where can we benefit, either directly or indirectly from Erlang's concurrency model?

I am writing two small applications for this. The first is a semi-re-implementation of the Java Pet Store example. The second is a simple instant message server. Both intend to demonstrate the use, for example, of higher-order programming in the context of a real example. In the second example, I hope to demonstrate the usefulness of Erlang as a very good concurrent language with its efficient process model. Can Erlang demonstrate the idea that we can write things like instant message servers (particularly for the web) without the mental overhead of dealing with the problems around multi-threading? I admit that I am not good in multi-threading, but from what I coded up so far, I am so excited of what possibilities that can be done with Erlang.

I will, for sure, be utilizing ErlyWeb, and plan to write a couple of big tutorials when I am finished with my applications (along with the academic paper I will write.)

I am going to post something up here occasionally of whatever activity that is happening in my little world; hopefully people will be interested. (hehehehe)

... also, check out Joe Armstrong's new Prgamatic Programmer book, Programming Erlang: http://pragmaticprogrammer.com/titles/jaerlang/index.html

People are actually reading this?

2006-12-21T11:13:00.000-08:00

Hmm, I never drew any popularity to any of my prior silly weblog attempts until now.It must be the tutorial that I put up. :D

Thanks for all the comments thus far.

OO That Looks Like Procedural Programs

2006-12-19T09:43:00.000-08:00

I wrote this to a couple of people on a private mailing list I am on:

"OO has never lived up to the potential for me, for precisely the
reason that most 'OO type' work I do (mostly via web apps) all tends to look like
procedural applications just with OO constructs around it. Get rid of
the OO constructs, and you pretty much got the same program, just
without the OO overhead. So why should I bother with OO? This is one
of the motivations that led me to functional programming. All the good
practices that is present OO still stand (like hiding implementation
from interface, the use of opaque values (related with the first one),
polymorphic functions), but it just doesn't think it is necessary to
bind data and bahavior together. Higher-order functions seem, right
now, to make sense more, for reusability purposes now than through
inheritance (ask my opinion on it after I developed some non-trivial
stuff with functional languages :))"

I worked in Rails and I played with Python a lot in these areas. My belief stems from this change in perspective:

Objects in Python are glorified dictionaries, or dictionaries with OO logic. If inheritance is necessary, then the OO logic is useful. But, eh ... I don't use inheritance. At most, I use tables to inherit similarities, using joins to accomplish that type of goal. I don't know what other people do, but I never used inheritance in such a grand way to actually see a use for it.

So, looking at something like ErlyDB, and its simple use of tuples, confirmed my point. I just got lazy a little.

The question is: is there anything special when it comes to merging data and functions together. For what I do, I just can't see it.

I said in the first tutorial that ErlyWeb (+ erlhive, but I haven't had a chance to look at that yet) is a Rails killer. Let me elaborate on that. It might not be flush with so many features as Rails does, but the constructs are much more simpler in ErlyWeb. The thing is that ErlyWeb is not this big opaque library of magic tricks; it doesn't need to be, no matter how many "opinions" are shoved into it.

But I think this pretty much reflects not so much the capabilties of a language, but the opinion of the language community. Where Rails says "you are stuck with the whole methodology that Rails has to offer", ErlyWeb should say "here is a few interesting tools to get you moving - other than that, everything is pretty much intuitive after that" This is why I think it could draw people to Erlang. I like that.

ErlyWeb Tutorial Part 2

2006-12-11T14:23:00.000-08:00

I have been looking forward to getting back to adding to this tutorial, but I have not had the chance the past few days. Now that I have a little time, I can jump in and finish the tutorial. What this part of the tutorial will address is the edit functionality for our blog application. Taking a hint from the CRUD functions that is in ErlyWeb, I will do something similar.

(Tip for Erlang newbies: use m(module_name) to find out about what functions are exported from a module. Very handy feature!)

ErlyDB looks like a smart fellow, because it knows that, despite using basic tuples, can figure out if the data is in the database or not. It probably isn't anything special, and Yariv will probably agree (since he wrote it), but it is interesting nonetheless.

I said this for a reason. We can similify our code, transforming the functionality in new_post/1 into something that calls a generic function, new_or_edit/2, which will also handle post editing. This is possible because ErlyDB saves records with same function.

In your entries_controller.erl file, get rid of the new_post/1 function, and then stick this in:


new_post(Vals) ->
 Entry = entries:set_fields_from_strs(entries:new(), Vals),
 new_or_edit(Entry, Vals).

We exported most of the logic that was in new_post/1 into new_or_edit/2. Put the new_or_edit/2 function in:



new_or_edit(Entry, Vals) ->
 EntryV = entries:set_fields_from_strs(Entry, Vals),
 Errors = helpers:validate(entries_validate, entries, EntryV),
 
 case Errors of
  ok ->
   entries:save(EntryV),
   {ok, EntryV};
  _ ->
   {Errors, EntryV}
 end.

It is a fact that this function applies to both creating a new entry and editing an entry. This is true because what we are going to show now, with the edit functionality. Put this code in:


%% Edit functions.

edit(A, Id) ->
 case yaws_arg:method(A) of
  'GET' ->
   {data, {"", edit_get(Id)}};
  'POST' ->
   Vals = yaws_api:parse_post(A),
   {Errors, Entry} = edit_post(Vals, Id),
   case Errors of
    ok ->
     {ewr, entries, index};
    _ ->
     {data, {Errors, Entry}}
   end
 end.


edit_get(Id) ->
 Entry = entries:find_id(Id),
 Entry.

edit_post(Vals, Id) ->
 Entry = entries:find_id(Id),
 new_or_edit(Entry, Vals).

WAIT A MINUTE! We are doing almost the same thing that is being done in our new function! Time to do some parameterization, to get rid of that look of cut-and-paste yuckiness. Look at where the differences are ... The function that is called to get an entry in "GET" and possibly, the space where we do a redirect. Let's add a library function! But, for you neophytes to functional programming ... we are going to use higher-order functions.

Here is the generic function:



form_process(A,
             GetAction, 
      ModelAction,
      PostSuccessAction, 
      PostFailureAction) ->
 case yaws_arg:method(A) of
  'GET' ->
   GetAction();
  'POST' ->
   Vals = yaws_api:parse_post(A),
   {Errors, Record} = ModelAction(Vals),
   case Errors of
    ok ->
     PostSuccessAction();
    _ ->
     PostFailureAction(Errors, Record)
   end
 end.

Essentially, the form_process/5 function is just a generalization of what we have been doing before. Except, this time, we replaced the specific places with function calls - to functions we will define in our new/1 function.


new(A) ->
 GetAction = fun() ->
   {data, {[], new_get()}} end,
 ModelAction = fun(Vals) ->
   new_post(Vals) end,
 PostSuccessAction = fun() ->
    {ewr, entries, index} end,
 PostFailureAction = fun(Errors, Entry) ->
    {data, {Errors, Entry}} end,
 
 form_process(A, GetAction, ModelAction, PostSuccessAction, PostFailureAction).

and then edit/1:


edit(A, Id) ->
 GetAction = fun() ->
   {data, {[], edit_get(Id)}} end,
 ModelAction = fun(Vals) ->
   edit_post(Vals, Id) end,
 PostSuccessAction = fun() ->
   {ewr, entries, index} end,
 PostFailureAction = fun(Errors, Entry) ->
   {data, {Errors, Entry}} end,
 
 form_process(A, GetAction, ModelAction, PostSuccessAction, PostFailureAction).

(NOTE! For some weird reason, when I am running new/1 through the browser, and hit submit, it takes a bit too long to load. Is this a bug in my code? edit/1, though, works like a charm. Go figure.)

So, we developed a pattern using common code and, more importantly, a common convention, meaning a common set of expectations. There is nothing grandiose about the convention, and yes, you can completely ignore it. The lines of code in my function is not my concern, but whether or not I can make the code more declarative, in the sense that I say "do this in this location, do this in this other location." But, I am thinking that the code there can be tightened up even more.

In your entries_view.erl file, add these functions:


new(Data) ->
 entry_form:display_form(Data, "../new", "").

edit(Data) ->
 entry_form:display_form(Data, "../edit", 
      integer_to_list(entries:id(element(2,Data)))).

Yep, we are using the same form for editing and displaying. However, we made a change. I needed to make the action in the form generic. So the new parameters represent the url to go to. I moved the form to its own module, in a file called "entry_form.et" - I am going for some sense of template organization, by putting one page per ErlTL file. But, I originally put it in "entries_show.et". Note the changes I made with the parameters. Here is the new lines:


<%@ display_form(Items, GoTo, Id) %>

and

< form action="<% GoTo %>/<% Id %>" method="POST" >

We also want to make a small addition, by adding a "view" function. This one is quite simple. In your entries_controller.erl file, add this function:


view(A, Id) ->
    Entry = get_entry(Id),
    {data, Entry}.

In your entries_view.erl file, add this function:


view(Data) ->
    entry_view:view(Data).

Add a file called "entry_view.et" for the view, and add this to the file:


<%@ view(Data) %>
< b><% entries:title(Data) %>< /b>
< br />< br />
<% entries:body(Data) %>
< br />

< i>by: <% entries:author(Data) %>< /i>
< br />< br />
<% erlyweb_html:a(["../edit", integer_to_list(entries:id(Data))], "Edit Entry") %>

Maybe, also, add a link to the view in your entries_show.et file.


<% erlyweb_html:a(["view", integer_to_list(entries:id(Entry))], "view") %>

Put it in your entry/1 function in the template.

Also, maybe you can finish off the show_entries/1 function in the same template file with a link to the new entry form. I'm lazy - you do it yourself. :)

Now, go to Yaws, type "start:boot()" and go to your index page. All of the elements should be visible. Is it? Any problems? If there is, this is a good time to learn what Erlang is saying to you. :P Now, if there is a problem in the tutorial, do contact me.

ErlyWeb - Blog Tutorial

2006-12-04T13:41:00.000-08:00

UPDATE: I am going to expand this tutorial a bit, later on, but, as of now, the tutorial can stand on its own. I only included a discussion on displaying blog entries and creating new entries. Later, I will be adding a discussion on adding an edit page and adding delete functionality.

A week ago, I started to play with Erlang. I wanted to look into web development with functional languages, so I invested time in a certain toolkit called ErlyWeb.

Here is a small tutorial of creating a simple weblog application in it. I am assuming you went through the musician tutorial, which explains in detail, getting Erlang, ErlyWeb, MySQL, blah blah blah. This tutorial is just a rough sketch of discoveries I made while using it.

(I typed this really quickly. So, if you try this, you need to fix all the HTML ... Blogger was rendering the HTML and I am too tired to find out why. So, I merely stuck a space after each < for now. I'll fix later.)

To start, we need to create an application like such, in the erl shell:


erlyweb:create_app("blog", "/path/to/apps").

Then, we create a table in MySQL, like such:


create table entries (
  id integer auto_increment primary key,
  title varchar(100),
  body text,
  author varchar(100)
);

We create an entries component:


erlyweb:create_component("entries", "/path/to/apps/blog").

While here, create a file called "entries_validate.erl" in your "src" directory in your app directory.

I created a small file that I put on the root of the blog directory which will start up a MySQL connection in ErlyDB as well as compile the whole app. I put this file on the root of the blog directory (and will reference to this place in other places in the tutorial.) Here is the file (edit where necessary):


-module(start).
-export([boot/0, boot/1]).


boot() ->
boot(true).
boot(false) ->
compile();
boot(true) ->
mysql_start(),
compile().

mysql_start() ->
erlydb:start(mysql, [{hostname, "localhost"},
      {username, "username"},
      {password, "password"},
      {database, "blog"}]).

compile() ->
erlyweb:compile("/path/to/app/blog",
  [{erlydb_driver, mysql}]).

This comes in handy, if you restart yaws, for example - you don't need to type in the connection function every time.

Edit your yaws.conf file:


< server junk >
  port = 8000
  listen = 127.0.0.1
  docroot = /path/to/blog/www
  appmods = <"/blog", erlyweb>
  
  appname = blog
  
< /server >

Then, start yaws:


yaws -i

Cruise over to your localhost:8000/blog/entries page, and enter a few new entries, for some starter data.

In your src/components/entries_controller.erl file, comment out the erlyweb_magic line. We are turning off the stuff we were using just before.

Now, we will start with the front page. We will want to create an index function that merely shows all the entries on the screen. In the entries_controller.erl file, enter this function in:


index(A) ->
   Entries = entries:find(),
   {data, Entries}

and put in your export line:


-export([index/1]).

What that function is merely saying is that it should get all the entries in the the entries table, and send the entries off to the view function.

Open up entries_view.erl, and enter this:


index(Data) ->
   entries_show:show_entries(Data).

and in your export line:


-export([index/1]).

In our view function, we are getting the data ("Entries") from the controller function, and now we are merely passing the data to the display function. Make a file called "entries_show.et" in the src/components directory and enter this code in:


<%@ show_entries(Entries) %>

<% [entry(E) || E <- Entries] %>


<%@ entry(Entry) %>

<% helpers:value(entries:title(Entry)) %>



<% helpers:value(entries:body(Entry)) %>


 by: <% helpers:value(entries:author(Entry)) %>

We are almost done. In the current version of ErlyWeb, I was having problems when the value of a particular field, like the output from entries:title(), would return undefined, and it would crash the yaws process (of course, it is not going to crash the server!) So, I created a small set of functions in a "helpers" module. Make this file in your src directory, and add this code:


-module(helpers).
-export([value/1]).

value(Val) ->
case Val of
 undefined ->
  "";
 _ ->
  Val
end.

We'll use this little code snippet for now.

Now, go to the root of the blog directory (you can use the cd() function in yaws, so you don't have to go back to your shell) and type:


start:boot().

Hopefully, everything will be fine. It will finish up with a tuple starting with "ok" at the beginning.

Go to your page, http://www.localhost:8000/blog/entries and you will hopefully see, in all its glory, the records you entered in before.

Now, we are going to expand the helpers module. Here is the complete helpers module file:


-module(helpers).
-export([value/1, validate/3]).

value(Val) ->
case Val of
 undefined ->
  "";
 _ ->
  Val
end.

validate(ValidatorModule, Model, Item) ->
Fields = Model:use_fields(),
Results = [ValidatorModule:Field(Model:Field(Item)) || Field <- Fields],  
Errors = [Error || Error <- Results,element(1, Error) == error],    
case Errors of   [] ->
  ok;
 _ ->
     Errors
end.

We added a validation function here. We are going to add a simple form to the mix; something to add new entries.

Back in the entries_controller.erl file, enter in this code:


new(A) ->
case yaws_arg:method(A) of
 'GET' ->
  {data, {[], new_get()}};
 'POST' ->
  Vals = yaws_api:parse_post(A),
  {Errors, Entry} = new_post(Vals),
  case Errors of
   ok ->
    {ewr, index};
   _ ->
    {data, {Errors, Entry}}
  end
   end.


new_get() ->
   Entry = entries:new(),
   Entry.

new_post(Vals) ->
Entry = entries:set_fields_from_strs(entries:new(), Vals),
Errors = helpers:validate(entries_validate, entries, Entry),
case Errors of
 ok ->
  entries:save(Entry),
  {ok, Entry};
 _ ->
  {Errors, Entry}
end.

and our export line:


-export([index/1, new/1, new_get/0, new_post/1]).

(We could make the new_get/0 and new_post/1 functions private to the web, but we'll consider this later.)

The new/1 function is the function that is exposed to the web. I split the logic of supplying a new form and creating a new entry because it will prove easier to unit test instead of mucking around with making a value to submit into new/1.

For GET in new/1, we merely drop in a new entries tuple into the form:


'GET' ->
   {data, {[], new_get()}};
...

new_get() ->
   Entry = entries:new(),
   Entry.

I return from new/1 in the 'GET' case with a "data" tuple, with a 2-tuple. The first item in the 2-tuple is an empty list - for the 'POST' part, we would use that location in the 2-tuple for errors. The second location is the entry we are considering.

For 'POST':


 'POST' ->
  Vals = yaws_api:parse_post(A),
  {Errors, Entry} = new_post(Vals),
  case Errors of
   ok ->
    {ewr, index};
   _ ->
    {data, {Errors, Entry}}
  end

Here, we get all the values from the post payload, and then run the new_post/1 function. If new_post/1 returns {ok, Entry}, then it will redirect to the index page. If not, it will show the form again, and display the errors, and fill in the form elements that are already filled in. Here, we can see now the corollary between the return value in 'GET':


{data, {Errors, Entry}}

"Errors" contains a list of tuples containing our error messages. The Entry variable contains an ErlyDB tuple that we received from new_post/1. Let's look at new_post/1.


new_post(Vals) ->
Entry = entries:set_fields_from_strs(entries:new(), Vals),
Errors = helpers:validate(entries_validate, entries, Entry),
case Errors of
 ok ->
  entries:save(Entry),
  {ok, Entry};
 _ ->
  {Errors, Entry}
end.

Here, when we get the values from the post payload, we convert the values into an entries tuple. Then, we submit into our validate/3 function (from before) with any errors. If validate/3 returns ok, then there were no errors. Otherwise, we will return the errors.

validate/3 takes the name of your validation module, your model module and the actual data tuple.

I said to create an entries_validate.erl file. Let's create that.


-module(entries_validate).
-export([title/1, body/1, author/1]).

title(undefined) ->
{error, title, "The title field is blank."};
title(_) ->
 ok.

body(undefined) ->
{error, body, "The body field is blank."};
body(_) ->
ok.

author(undefined) ->
{error, author, "The author field is blank."};
author(_) ->
ok.

In entries.erl, put this:


-export([use_fields/0]).

use_fields() ->
[title, body, author].

The validate/3 function loops through the list of names from use_fields() and checks the data in the model tuple, using the functions you provide in entries_validate.erl.

(I say, isn't validation extremely simple in ErlyWeb? A tiny function to get rid of boilerplate code, and a small convention on how to present the data, and that's it!)

Once you got validation in place, enter this into your entries_view.erl file:


new(Data) ->
entries_show:display_form(Data).

and the export line:


-export([index/1, new/1]).

and now, the form, which we will stick also at the bottom of entries_show.et:


<%@ display_form(Items) %>
<%? {Errors, Data} = Items %>
<% helpers_html:show_errors(Errors) %>

< form action="new" method="post">
< table>
< tbody>< tr>< td valign="top">Title:< /td>
< td>
<% erlyweb_html:input("title", text_field, undefined, helpers:value(entries:title(Data))) %>
< /td>
< /tr>

< tr>< td valign="top">Body:< /td>
< td>
<% erlyweb_html:input("body", text_area, undefined, helpers:value(entries:body(Data))) %>
< /td>
< /tr>

< tr>Author:< /td>
< td><% erlyweb_html:input("author", text_field, undefined, helpers:value(entries:author(Data))) %>< /td>
< /tr>
< tr>< input value="Submit" type="submit">< /td>< /tr>
< /tbody>< /table>
< /form>

Hopefully, all this code is self-evident.

Before we finish, one more thing. I added a small module in ErlTL called helpers_html.et in my src/ directory:


<%@ show_errors(Errors) %>
< ul>
<% [error(E) || E <- Errors] %>
< /ul>

<%@ error(Error) %>
< li><% element(3, Error) %>< /li>

This will show us our errors, if we make a mistake in our form.

Now, back in yaws, type in:


start:boot().

and go back to your browser and go to localhost:8000/entries/new.

Make a mistake. Hit submit. Do you see the errors pop up? Fill in the form correctly. Does it go to the index page properly? If so, we have a simple blog app working.

Of course, I totally ignored editing posts in this tutorial. Maybe I will add this later. But, I hope you are seeing what I am seeing. ErlyWeb has INCREDIBLE POTENTIAL, since it avoids a lot of complexity. Any gaps we found thus far were easily plugged in. Even though ErlyWeb is new, this, so far, blows Rails out of the water in terms of brevity. Of course, it took me longer to figure this all out how to do this, since the docs are not up to par yet. Hopefully, this can be fixed soon.

Haskell Stacks : Two Different Ways

2006-11-14T19:13:00.000-08:00

I am starting to attempt to understand how Haskell can persist functions sans the variables. You can do it with lists, already. There are plenty of functions that demonstrate the concept. But I want to expand further. I want to try implementing a stack with a list, and then do it with a recursive type. This is what I have for the first one:



putAtEnd [] item = [item]
putAtEnd (x:xs) item = x : putAtEnd xs item

push lst item = putAtEnd lst item
-- or
-- push lst item = reverse (item : (reverse lst))

pop lst = pop_ lst ((length lst) - 1)

pop_ _ 0 = []
pop_ (x:xs) len = x : pop_ xs (len - 1)

-- or
-- pop lst = reverse (tail (reverse lst))

I thought the reverse function was neat, but seemingly costly. But, from the Prelude:



reverse :: [a] -> [a]
reverse = foldl (flip (:)) []

flip f x y = f y x

foldl f z [] = z
foldl f z (x : xs) = foldl f (f z x) xs

We can see a really slick way of doing reverses. "reverse" is merely a function curry of a foldl waiting for the last parameter. Let's see if it is costly:


reverse [1,2,3,4]
 -> foldl (flip (:)) [] [1,2,3,4]
    -> foldl (flip (:)) (flip [] 1) [2,3,4]
    -> foldl (flip (:)) (1 : []) [2,3,4]
          -> foldl (flip (:)) (flip [1] 2) [3,4]
          -> foldl (flip (:)) (2 : [1]) [3,4]
                -> foldl (flip (:)) (flip [2,1] 3) [4]
                -> foldl (flip (:)) (3 : [2,1]) [4]
                      -> foldl (flip (:)) (flip 4 : [3,2,1]) []
                      -> foldl (flip (:)) [4,3,2,1] []
-> [4,3,2,1]

So, the ones with the same indentation are the same, except the second line is the flip function evaluated. It is what I expected, though. It takes O(n) (?) time (there are two operations on the data: one operation to flip, and another operation to add to the new list. So, maybe it is O(2n)? I forget my algorithm lessons.) It seems though, that the original implementation I provided performs the same though. Maybe expressing it via reverse then is easier.

Lists are, still probably still efficiently implemented, and those operations I am doing are turned into an iteration (tail-call recursion), plus some other magic I don't know about. I have to think of a nifty way of handling it faster though.

Anyway, the other idea I had was to make a stack a recursive data type:



data Stack n m = Item m | StackFrame ((Stack n) (Item m))

-- so ... 

(StackFrame (StackFrame (Item 1) (Item 2)) (Item 3))

-- looks like

-- 3
-----
-- 2
-----
-- 1
-----

What a wacky idea. I have to think about this one, and read some common examples on this.

Haskell Golf Scores

2006-11-13T12:49:00.000-08:00

I am tutoring someone in Java. We did an example program of summing up the golf scores of a number of people. I was interested in showing him some MVC design principles, as it will be useful for his end-of-year project.

I decided to improve my understanding of Haskell today, by reimplementing it in Haskell. It lacks MVCishness, but it's still nice. I also couldn't find a function to convert from strings to integers, so I implemented one quickly using a number->int function. It is not perfect, since it does conversions to hex digits, but it is a start.

Can I improve on it? Please do comment. ;)


module GolfScore where

import Data.Char

toNumber str =
 let slen = length str
 in
   toNum_ str ((length str) - 1) 0

toNum_ :: [Char] -> Int -> Int -> Int
toNum_ str (-1) val = val

toNum_ str count val =
 let currVal = (str !! count)
 in toNum_ str (count - 1)
        (val + ((digitToInt currVal) * (10 ^ (((length str) - 1) - count))))

----------
-- main
----------
run count holes = run_ count holes [] []

run_ 0 holes lstName lstRes = showResults (reverse lstName) (reverse lstRes)
run_ count holes lstName lstRes =
   do putStr "Enter name: "
      n <- getLine
      scores <- getAndAddScores holes []
     
      run_ (count -1) holes (n : lstName)
               ((foldr ((+) . toNumber) 0 scores) : lstRes)


showResults [] _ = return ()
showResults (x:xs) (y : ys) =
   do
     putStr x
     putStr " got a score of: "
     print y
     showResults xs ys   


getAndAddScores 0 scores = do return scores
getAndAddScores holes scores =
   do
      putStr "Enter score: "
      score <- getLine
      getAndAddScores (holes - 1) (score : scores)

This Weblog

2006-11-13T12:48:00.000-08:00

I am going to post random samples of code that look interesting to me in languages I am trying out. Right now, I have to look at other programming languages that I do not completely know. It will start off with a lot of Haskell and Ada code.