Converting the ASP.NET MVC project into OpenID

When you create an ASP.NET MVC project it comes with a controller called AccountController that manages logging in, logging out, registering, changing password and so on. Since usernames and passwords are dead I converted it into OpenID and I’m just pasting it here for everybody to use.

I’m using the DotNetOpenAuth library which you have to download, put in your project and refer. The difference between what I’m pasting and the example provided by DotNetOpenAuth is that I’m actually storing the user in the membership database, like the original AccountController.

My work is based on the on the blog post Adding OpenID to your web site in conjunction with ASP.NET Membership. I really had to put a couple of hours on top of that, so I consider it worth it to post it. Scott Hanselman also provides useful information for integrating OpenID. I’m using the jQuery OpenID plug-in but I’m not going to post my views. They are really trivial and left as an exercise to the reader.

I’m not using any extra tables, I’m storing the OpenID identifier (the URI) in the field for the username. This has the advantage of not requiring any other fields but the disadvantage that you can have only one identifier per user. There are some unfinished parts but since you are likely to customize them anyway, I don’t feel too guilty about not finishing yet. If you find a bug, please, let me know.

Continue reading “Converting the ASP.NET MVC project into OpenID”

How to create a Clojure application

Update: this is not my preferred way to create a Clojure application and shouldn’t be yours either, check out Leiningen

This is one of those posts that I publish partly for myself. And partly so people can criticize my way, which is also for myself, and only incidentally for others to learn from it.

It seems Maven is popular in the Clojure world. Clojure itself uses it, Webjure uses and its demo application uses it as well, there’s a branch for Compojure that uses too. So after building all those components using Maven I’ve decided to use it myself when building Clojure applications.
Continue reading “How to create a Clojure application”

Printing emails in Django

When developing applications in Django, it may be nice to print emails instead of sending them. If you send them you have to be careful which addresses you use. Just being on the safe side and always using @example.{com,org,net} is not enough, you have to use an address you can actually retrieve emails for. And you have to configure your development environment to actually deliver mails. And then wait for the whole thing in each code-try iteration.

So, basing myself on the testing code, I’ve added this to settings.py and mails are now printed:

if DEBUG:
 from utils import BogusSMTPConnection
 from django.core import mail
 mail.SMTPConnection = BogusSMTPConnection

Of course you’ll also need the BogusSMTPConnection class, I’ve defined it as following:

from textwrap import wrap
class BogusSMTPConnection(object):
  """Instead of sending emails, print them to the console."""

  def __init__(*args, **kwargs):
    print("Initialized bogus SMTP connection")

  def open(self):
    print("Open bogus SMTP connection")

  def close(self):
    print("Close bogus SMTP connection")

  def send_messages(self, messages):
    print("Sending through bogus SMTP connection:")
    for message in messages:
      print("tFrom: %s" % message.from_email)
      print("tTo: %s" % ", ".join(message.to))
      print("tSubject: %s" % message.subject)
      print("t%s" % "nt".join(wrap(message.body)))
      print(messages)
      return len(messages)

And that’s it.

Pylons or Django?

I am trying to decide whether to use Pylons or Django. Both are frameworks for building Python web applications, but with opposing philosophies.

Django tries to be everything. It comes with its own ORM, its own template engine, its own everything. That gives you a nice developing experience because everything fits together and because very nice applications can be built on top of all those components, like the admin tool, which is amazing. Continue reading “Pylons or Django?”

“Programming Languages: Application and Interpretation” now in paperback

Programming Languages: Application and Interpretation, the best book I’ve found on creating your own programming language is now available in paperback.

You can still get a free-of-cost copy of Programming Languages: Application and Interpretation at its original site. Actually, the book is now released under a Creative Common license, thank you Shriram!

This is, actually, old news. The book has been in paperback for quite a while, but I neglected to publish the post at that time. Today, a chat at the Esperanto meeting about Lulu (and how useful it is for Esperantists, that make books nobody wants to publish) reminded me about the post and I’m now publishing it.

Quick and dirty continuous testing with Ruby on Rails

I like the idea of continuous testing: seeing that you broke it, the moment you broke it and the same for fixing. There are some tools to do it, but since they are not packaged, yet, for my operating system of choice I went through the quick and dirty route:

watch -n 5 rake test 2> /dev/null

Continue reading “Quick and dirty continuous testing with Ruby on Rails”

Another simplistic solution, with SCons

SCons is a program designed to replace make and autotools. SCons being a new tool is built with all the knowledge of what problem really this kind of tool should be solving, while make and autotools were built while discovering the real problem. It is natural to expect SCons to have a better design that covers the big picture. Continue reading “Another simplistic solution, with SCons”

Solving Lisp’s problem: a simplistic solution with make

I recently stated what I believe is the biggest problem with Lisp, you can’t make programs with it. In my quest, my first solution is a very simplistic Makefile that does the job using cl-launch, a very interesting program that can turn a Common Lisp program into a Bash script. Other solutions are likely to use cl-launch as well.

So, we’ll play with this little program:

(defun main ()
  (format t "Hello world!~%"))

(main)

Very trivial indeed. And to “compile it”, we’d use this trivial Makefile:

%: %.lisp
        cl-launch --output $@ --file $&<

hello-world: hello-world.lisp

All we have to do now is run make:

$ make
cl-launch --output hello-world --file hello-world.lisp

And we now have a runable hello-world:

$ ./hello-world
Hello world!

It run! it worked! it’s portable! Isn’t it great?

Obviously all the logic is hidden inside cl-launch (thank you Fare Rideau). The problems with this simple solution is that using only make makes programs harder to port and package for different distributions and operating systems. That’s why the autotools where invented. Remember those days when to compile something we had to open a Makefile and set up variables? well, this simplistic solution is going back to those days. We can do better, I hope I can do better.

Now, for the curious, this is how the hello-world script looks like (I’d say its quite remarkable):

#!/bin/sh
#| CL-LAUNCH 2.03 CONFIGURATION
SOFTWARE_FILE=.
SOFTWARE_SYSTEM=
SOFTWARE_INIT_FORMS=
SYSTEMS_PATHS=
INCLUDE_PATH=/usr/share/common-lisp/source/cl-launch
LISPS="cmucl sbcl clisp ecl openmcl gclcvs allegro lisp gcl"
WRAPPER_CODE=
DUMP=
RESTART=
IMAGE_BASE=
IMAGE_DIR=
IMAGE=

# END OF CL-LAUNCH CONFIGURATION
# This file was generated by CL-Launch 2.03
# This file was automatically generated and contains parts of CL-Launch
#
PROG=""
. /usr/share/common-lisp/source/cl-launch/wrapper.sh

launch_self "$@"

ABORT

# |#

(load "/usr/share/common-lisp/source/cl-launch/header.lisp" :verbose nil :print nil)

;;;; CL-LAUNCH LISP INITIALIZATION CODE

#-cl-launched
(cl-launch::run :load :self)

;;;; END OF CL-LAUNCH LISP INITIALIZATION CODE

;;; 65bcc57c2179aad145614ec328ce5ba8 SOFTWARE WRAPPED BY CL-LAUNCH BEGINS HERE:

(defun main ()
(format t "Hello world!~%"))

(main)

The problem with Lisp

I’m not really going to talk about the problem with Lisp, but only a problem. And I’m not really going to talk about Lisp, but Common Lisp. So this post should be called “A problem with Common Lisp”, but the current title is more catchy, isn’t it?

You are still with me? nice. Because I believe I have something important to say. A problem with Common Lisp is that you can’t make programs with it. That may have been another nice catchy title: “You can’t make programs with Lisp”. Continue reading “The problem with Lisp”

Lisp macros feel like cheating

Common Lisp macros feel like cheating. I’ve reached chapter 9 of Practical Common Lisp, where the goal is to build a unit test framework, and you can see right away how the patterns are easily abstracted out with macros. It’s so easy it feels like cheating.

Getting a text representation of the test code to be able to point what when wrong, to show the piece of code failing, is supposed to be a hard task. Well, it is a hard task, sometimes impossible, in most programming languages. In Common Lisp it’s so trivial, it feels like cheating.

If you want to know what Lisp is about, read up to chapter 9 of PCL (Practical Common Lisp), at least. I used to tell people to at least read chapter 3, but it seems not to be enough, sadly, to impress the average programmer (either because they just don’t see it or chapter 3 is still too basic).

Comments at the original blog

Nubis Says:

Hey, good point. You know what also feels like cheating to me? The loop language.
I mean, from the 99 lisp problems:
Flatten a tree of lists:

(defun flatten (list)
  (loop for i in list if (listp i) append (flatten i) else collect i))

or, remove duplicated values from a list

(defun makeset (list)
  (loop for i in list unless (find i set) collect i into set finally (return set)))

At first it looks like cheating, but then i realized that the loop language is to lists what regular expressions are to strings, and it’s better than having a bunch of different people writing their loops and boilerplate in different ways.

best regards
—-nubis

September 3rd, 2007 at 4:30 e