May 2012 - web-devel - Haskell.org

Estágio com Haskell em SP (Haskell internship at São Paulo, Brazil)
by Felipe Almeida Lessa 28 May '12

28 May '12

(English message follows after the break.) Olá! Estamos procurando um estagiário para trabalhar conosco em São Paulo capital. Nós somos uma startup apaixonada por Haskell com uma boa participação na comunidade e grandes projetos e desafios! Se você está interessado, basta me mandar um e-mail (felipe.lessa(a)gmail.com) com um link para sua conta do GitHub (ou para projetos em que você já tenha trabalhado). Você não precisa ser experiente em Haskell nem ter nenhum código Haskell publicado, mas isso seria um diferencial =). Como a startup está em stealth mode, não posso divulgar o nome da empresa e por isso estou usando meu e-mail pessoal. Até mais! === Hey! We're looking for an intern to work with us in São Paulo, Brazil. We're a startup passionate about using Haskell with great projects and challenges! If you're interested, just send me an e-mail (felipe.lessa(a)gmail.com) with a link to your GitHub account (or to any projects you've worked at). You don't need to be an experienced Haskeller nor have any published Haskell code, but that would be a plus =). As the startup is in stealth mode, I can't disclose the company's name nor use my work e-mail (that's why I'm using my personal one). Cheers, -- Felipe.

2 1

happstack subdomain routing
by Asafe Ribeiro 27 May '12

27 May '12

How do I do subdomain routing on happstack?

2 1

RFC: Upcoming change in yaml parsing
by Michael Snoyman 24 May '12

24 May '12

Hi all, Before releasing to Hackage, I wanted to see if anyone has objections to an upcoming change in the yaml library. The issue[1] is that values that can be parsed as numbers are currently treated as numbers, even if they're quoted. The change will instead treat any quoted value as a string, and only unquoted values will be parsed. In other words: Currently: decode "'1234'" == Number 1234 Changed: decode "'1234'" == String 1234 (Note the single quotes inside the double quotes.) This will cause a small change in semantics, and in theory could break people's code, though frankly I think the current behavior is a bug. If people have objections to the change, let me know. Michael [1] https://github.com/snoyberg/yaml/issues/8

1 1

ANN: reform - a type-safe form generation and validation library in the spirit of formlets and digestive-functors < 0.2
by Jeremy Shaw 22 May '12

22 May '12

I am pleased to annouce the release of 'reform'. A full tutorial is available here: http://www.happstack.com/docs/crashcourse/Reform.html Reform is an HTML form generation and validation library. It follows in the footsteps of formlets and digestive-functors <= 0.2. In fact, much of the code in reform comes from the digestive-functors-0.2 code base. Reform is designed to be usuable with a wide variety of Haskell web servers and templating libraries. You can find the following packages on hackage: * reform - the core library * reform-happstack - support for using reform with the Happstack server * reform-blaze - support for creating forms for blaze-html * reform-hsp - support for creating forms for HSP (another xml/html template library) The source code is available via darcs: darcs get http://patch-tag.com/r/stepcut/reform The darcs repo also includes proof-of-concept support for 'Heist'. Reform will feel very familiar to formlets and digestive-functors <= 0.2 users. The primary motivation behind this library is to provide a supported alternative to digestive-functors 0.2 for users that prefer 0.2 over 0.3. The key new feature in reform is the ability to separate the validation code from the view generation code. This allows library authors to provide validators (known as Proofs) which the users can use when constructing their forms. The proof names appear in the type-signatures. This allows the library author to ensure that the value returned by a user created form is not merely the correct type, but has also passed validation. The reform-happstack package also provides simple and transparent Cross-Site Request Forgery (CSRF) protection, using the double-submit method. This method has some weaknesses. For example, I believe it can be circumvented if your site is vulnerable to cross-site scripting (XSS) attacks. If you have suggestions on how to improve the CSRF protection -- please let us know! I hope to do a full comparison of reform vs digestive-functors 0.3 vs yesod forms in a few weeks. - jeremy

3 3

Snap authentication with openid?
by . 17 May '12

17 May '12

Hello web-devel, I have a question about the snap framework: I found the Auth snaplet. As far as I understood (I haven't quite figured out yet how to use that thing in practice), it allows for authentication of users when the username and password are stored locally. Is there a way to use openID for authentication out of the box? If not, what would I need to do to make that work? I found the IAuthBackend, is that what I would have to implement then? Is there more documentation on that kind of stuff somewhere? A big thank you for any help and pointers! Christian

1 0

ANN: hissmetrics, server API access to KISSmetrics
by Felipe Almeida Lessa 14 May '12

14 May '12

Hello! I'm pleased to announce the hissmetrics package [2]. It's has unofficial API bindings to KISSmetrics that allows you to do everything the official bindings do as well. It's already at version 0.2.2, so grab it while it's hot! =D This package has been developed on my work time, so thanks to my nice employer. In the near future the copyright of the package will be transferred to my employer but the license will stay the same (BSD3). Cheers, =) [1] https://www.kissmetrics.com/ [2] http://hackage.haskell.org/package/hissmetrics -- Felipe.

1 0

"Wiki" section of the Yesod doc site
by Michael Snoyman 13 May '12

13 May '12

Hi everyone, I've added a new section to the Yesod doc site: the wiki[1]. This section is intended to be user-writable, so if you have any content you'd like to submit, please go ahead. In particular, this section contains the "Powered by Yesod" page: please add your sites. Unfortunately, the list from the old wiki was lost when my previous VPS died. (All my databases were backed up, I just forgot to backup the Wiki content as well...) Michael [1] http://www.yesodweb.com/page/wiki

5 7

Re: [web-devel] [Yesod] Re: Better web app deployment
by Douglas Livingstone 07 May '12

07 May '12

On 6 May 2012, at 11:00, web-devel-request(a)haskell.org wrote: > I was actually very specific about what we should do: send an > interrupt signal. In your case, you could catch that signal and allow > your long-running processes to finish. Likewise, an app which is has > any kind of long-running responses would want to take that approach. All apps will need a variation on this, since even if the individual responses are fast, they will need to be completed before the process can exit. I'm not sure how this affects restarting Nginx, how does it handle pending responses when asked to restart with a new config? Douglas

2 1

Re: [web-devel] [Yesod] Better web app deployment
by Michael Snoyman 05 May '12

05 May '12

On Fri, May 4, 2012 at 6:17 PM, Lyndon Maydwell <maydwell(a)gmail.com> wrote: > This is absolutely on par with what I've been thinking about over the > last week. I take it you are drawing some inspiration from the Twelve > Factor App Manifesto that you linked me to? It certainly seems that > way :-) > > I started building a management application to act as an interface for > this kind of architecture, however, I'm stuck grappling with the Yesod > form model as I haven't had much time to spend on it yet. > > A couple of ideas: > > Are you planning to have strong isolation between the applications > using some kind of sand-boxing? Given an Nginx reverse proxy this > should be made quite trivial by having the apps communicating over a > port or socket. Just a question of how it would be implemented. I wasn't planning on it, but you're right that it should be feasible. I suppose I've been taking the approach so far of letting the apps have much more freedom than say a Heroku deployment. The idea would be that only trusted apps would be running on the system. > I feel that a framework like this would benefit enormously from having > strong partnership with a continuous integration framework for > actually building the applications. This could run as an application > inside the application deployment framework in order to be nicely > circular! A benefit of this would be that you could guarantee that the > build and deploy architecture is the same - freeing developers from > the worry that their local machine is a different CPU architecture or > operating system. Like Greg said, the ideal would be building this on a separate virtual machine to avoid bogging down your app server with compilation. One possible idea would be to provide a nice, powerful EC2 instance as a community, and get a simple setup with Github commit hooks to be able to deploy from it automatically. I definitely want to explore this, but after the deployment system itself is in place. > > Love the idea. You're always a step ahead. > > On Fri, May 4, 2012 at 10:55 PM, Michael Snoyman <michael(a)snoyman.com> wrote: >> Hi all, >> >> (Note: I originally was going to just send this to the Yesod mailing list, >> but frankly, most of the code I'm setting up would work for any web >> framework. If people using other frameworks want to use this deployment >> code, and are interested in working with me to make sure it's universally >> applicable, please be in touch.) >> >> I'm planning on improving the deployment code starting next week. Instead of >> comparing to what we currently have (and which I think only I use), let me >> just give a high-level approach. Please give input on how you'd like to >> change things. Once I have the basic structure put together, I'll put it up >> on Github, and contributions will be greatly appreciated: >> >> * We'll use Nginx as a reverse proxy. This will allow us to have virtual >> hosting, more efficient static file serving (possibly from a separate >> domain), and zero-downtime deployments. >> * The scaffolding will accept a number of environment variables for >> configuring it, such as PostgreSQL connection information, approot, static >> root, and port number. (Most of this is already implemented.) >> * Each site will have a deployment configuration file, for things like >> domain name, whether a PostgreSQL database is required, and any system >> packages are required to be installed (we'll assume a Debian-based system >> for now). The deployer will automatically create databases and provide that >> information via environment variables. >> * Apps will have a specific file format, which is essentially a deployment >> config file and a bunch of things (static folder, executable, etc) it needs. >> An app will then be a tarball of those folders. >> * The deployer will watch a folder for changes. Deployments will be >> performed by copying files into this folder. >> * When a new app is deployed, it will be unpacked, started up, and >> monitored. If it stops, it will be restarted. The Nginx config file will be >> updated to reverse proxy to the app's port (randomly assigned) and then >> reloaded. >> * When a new version of the app is deployed, we'll unpack and start it up to >> a new folder with a different port. Once the app responds to an HTTP HEAD >> request (doesn't matter *how* it responds), we'll update the Nginx config >> file, reload Nginx, send the TERM signal to the old app, and then delete the >> old app's folder. >> * When an app is deleted, remove it from the Nginx config file, reload >> Nginx, send the app the TERM signal, and delete the folder. >> * We'll automatically store log files for apps (recommendations on good >> approaches here are welcome). >> * The deployer itself will provide a web interface to monitor status of apps >> and view logs. >> * I have no specific plans for running shell scripts or the like. I believe >> most of that can be part of the app loading. With the zero-downtime >> deployment, it's acceptable for the load time to be significant. If anyone >> has better ideas here, let me know. >> >> If we get a good deployment tool going, I think I would next want to set up >> an AMI (Amazon Machine Image) to make it dead simple to spin up an instance >> capable of hosting Yesod apps. If we can get it to configure DNS as well, >> and get a command line tool that automatically performs the EC2 instance >> creation, I think we'd be golden. >> >> Michael

1 0

Better web app deployment
by Michael Snoyman 05 May '12

05 May '12

Hi all, (Note: I originally was going to just send this to the Yesod mailing list, but frankly, most of the code I'm setting up would work for any web framework. If people using other frameworks want to use this deployment code, and are interested in working with me to make sure it's universally applicable, please be in touch.) I'm planning on improving the deployment code starting next week. Instead of comparing to what we currently have (and which I think only I use), let me just give a high-level approach. Please give input on how you'd like to change things. Once I have the basic structure put together, I'll put it up on Github, and contributions will be greatly appreciated: * We'll use Nginx as a reverse proxy. This will allow us to have virtual hosting, more efficient static file serving (possibly from a separate domain), and zero-downtime deployments. * The scaffolding will accept a number of environment variables for configuring it, such as PostgreSQL connection information, approot, static root, and port number. (Most of this is already implemented.) * Each site will have a deployment configuration file, for things like domain name, whether a PostgreSQL database is required, and any system packages are required to be installed (we'll assume a Debian-based system for now). The deployer will automatically create databases and provide that information via environment variables. * Apps will have a specific file format, which is essentially a deployment config file and a bunch of things (static folder, executable, etc) it needs. An app will then be a tarball of those folders. * The deployer will watch a folder for changes. Deployments will be performed by copying files into this folder. * When a new app is deployed, it will be unpacked, started up, and monitored. If it stops, it will be restarted. The Nginx config file will be updated to reverse proxy to the app's port (randomly assigned) and then reloaded. * When a new version of the app is deployed, we'll unpack and start it up to a new folder with a different port. Once the app responds to an HTTP HEAD request (doesn't matter *how* it responds), we'll update the Nginx config file, reload Nginx, send the TERM signal to the old app, and then delete the old app's folder. * When an app is deleted, remove it from the Nginx config file, reload Nginx, send the app the TERM signal, and delete the folder. * We'll automatically store log files for apps (recommendations on good approaches here are welcome). * The deployer itself will provide a web interface to monitor status of apps and view logs. * I have no specific plans for running shell scripts or the like. I believe most of that can be part of the app loading. With the zero-downtime deployment, it's acceptable for the load time to be significant. If anyone has better ideas here, let me know. If we get a good deployment tool going, I think I would next want to set up an AMI (Amazon Machine Image) to make it dead simple to spin up an instance capable of hosting Yesod apps. If we can get it to configure DNS as well, and get a command line tool that automatically performs the EC2 instance creation, I think we'd be golden. Michael

3 3