Lift http://lift.la The official Lift blog posterous.com Wed, 08 Feb 2012 10:58:00 -0800 Lift Basics and Broad Shoulders http://lift.la/lift-basics-and-broad-shoulders http://lift.la/lift-basics-and-broad-shoulders The Lift community is amazing.  It's a collection of more than 3,000 people building amazing apps with Lift.

The Lift committer group is amazing.  It's a collection of more than 50 people who put time and effort into writing the code in Lift and more importantly into creating an excellent, supportive environment in the Lift community.

Between the community and the committers, the shoulders that support Lift are indeed very broad and very strong.

I am honored and excited that Franz Bettag and I will be helping to broaden the knowledge, involvement and support of Lift by offering a 1 day Lift Basics course at Skills Matter in London on March 15th.  This will offer Franz the training necessary to teach "David Pollak's Lift Basics" to audiences in Germany (in German) as well as other places.

More importantly, it's yet another data point that demonstrates the amazingly broad shoulders that support Lift.  And stay tuned... there will be more announcements that underscore just how broad and strong the support for Lift is.

Permalink

]]> http://files.posterous.com/user_profile_pics/262685/dpp.gif http://posterous.com/users/36jxRzY3Z6x3 David Pollak David David Pollak Fri, 03 Feb 2012 11:53:49 -0800 The transition of scala-tools.org http://lift.la/the-transition-of-scala-toolsorg http://lift.la/the-transition-of-scala-toolsorg It's been a little slow in coming (those ship dates always slip), but the Sonatype folks will be taking over the hosting of Scala related artifacts from scala-tools.org.

Currently, Sonatype is rsyncing the entire scala-tools.org repository so that anything published to scala-tools.org will be mirrored up to Sonatype.

We have transferred the LDAP information for all the scala-tools.org such that you will be able to publish directly to Sontaype's servers.

In the next week or so, we will be pointing the DNS for nexus.scala-tools.org and other domains over to Sonatype's servers such that existing projects will be communicating directly with Sonatype's servers (we were hoping to do that before the announcement, but, well... things happen.)  We will also be 301-ing all incoming requests for artifacts to Sonatype's servers so that existing projects with existing configuration files will be getting the latest and greatest from Sonatype's servers.

Between now and mid-June, scala-tools.org will point to Sonatype's servers.  Once the redirects are in place and periodically thereafter, I will be making reminder posts to point configuration files to Sonatype's servers.  I will also send out periodic emails to the folks who have been publishing to scala-tools.org to update their configuration files to point to Sonatype's servers and to remind their communities to update configuration files to Sonatype's servers.

In mid-June, scala-tools.org will no longer redirect to Sonatype's servers.

I'd like to thank the Sonatype folks for being so helpful about transitioning the repository from scala-tools.org to the Sonatype servers.  I'd also like the thank Derek who came up for air and helped out with the LDAP stuff.

More information and technical specifics as they become available.

Permalink

]]> http://files.posterous.com/user_profile_pics/262685/dpp.gif http://posterous.com/users/36jxRzY3Z6x3 David Pollak David David Pollak Fri, 03 Feb 2012 09:46:33 -0800 DPP's Lift Office Hours Monday February 6th http://lift.la/dpps-lift-office-hours-monday-february-6th http://lift.la/dpps-lift-office-hours-monday-february-6th David Pollak will be available for Lift Office Hours to answer Lift-related questions either in person or on Skype from 11am to 3pm Pacific Standard Time.

Physical Location:
541 8th Street
San Francisco, CA 94121

Skype: lift-office-hours

Drop on by, give a call, I'll be glad to help!

Thanks,

David

Permalink

]]> http://files.posterous.com/user_profile_pics/262685/dpp.gif http://posterous.com/users/36jxRzY3Z6x3 David Pollak David David Pollak Tue, 24 Jan 2012 09:34:14 -0800 Monday Jan 30 11am - 3pm Lift Office Hours with @dpp http://lift.la/monday-jan-30-11am-3pm-lift-office-hours-with http://lift.la/monday-jan-30-11am-3pm-lift-office-hours-with Part of my ongoing commitment to Lift's growth and the success of Lift users and the Lift community, I will be doing "office hours" a couple of Mondays a month.

Office hours are an open invitation for anybody to drop by my office (541 8th Street in San Francisco) with Lift questions, suggestions, project demos or just to chat.

The first Lift Office Hours are from 11am PST to 3pm PST on Monday January 30th.

So, if you're in the Bay Area and want to chat, come on by.  There's plenty of coffee, tea, and other beverages.

Looking forward to meeting folks!

Thanks!

David

Permalink

]]> http://files.posterous.com/user_profile_pics/262685/dpp.gif http://posterous.com/users/36jxRzY3Z6x3 David Pollak David David Pollak Sat, 21 Jan 2012 09:45:00 -0800 No, I don't owe you scala-tools.org http://lift.la/no-i-dont-owe-you-scala-toolsorg http://lift.la/no-i-dont-owe-you-scala-toolsorg

Apparently I'm a jerk for shutting down scala-tools.org.  Apparently, I'm an egomaniac for deciding not to sell the domain for "more than $0" even though nobody has made a legitimate offer for the domain. [Note: James Iry asked the question on Twitter.  It was a perfectly reasonable question that I answered as best I could in 140 characters. I answered him and there were subsequent posts from others that personally attacked me for not doing things the way they think I should.  Posts from others who attacked me for talking about using scala-tools.org to mourn the losses that I see in Scala-land.  This post is *NOT* aimed at James.  I like James.  I respect James.  James represents some of the very best of the Scala community and he was one of the folks who energized me about Scala and gave me hope that Scala could be a "local maximum of research and practical in computer langages."  I am deeply sorry that James read this post as something about him.]

I plan to transition the scala-tools.org accounts and such to another provider.  These plans will be rolled out on Tuesday.  There will be ongoing support for a Nexus/Maven repository for the Scala community.  The community will continue to have a place to share components.

What I do not have an interest in is selling or transferring the scala-tools.org domain.  There is not a way to set a reasonable price for the domain.  The domain has value because of the brand built over the last 3+ years of its existence.  How do you price that?  How do you price the value that the domain has brought to the Scala community as a whole?  Whatever I think that monetary value is, it's likely a few orders of magnitude more than others think the value is.  It's not even worth, in my opinion, trying to price it.

So, what value does scala-tools.org have to me if not a monetary value?  That's up to me.  Sorry, to say, but it's my domain.  It's something that I've paid for, worked on, recruited others to work on.  Yes, there's a conversation to be had with DavidB and Derek for their work over the years.  There's less of a conversation to be had with Josh because, while he helped out, he also dropped to ball on the Nexus skills transfer to Indrajit and Lukas which precipitated my decision to close scala-tools after Lukas expressed extreme frustration with being ignored.  I also owe some obligation to Indrajit and Lukas for stepping up when I put out the call for help a few months ago.

To the rest of the community, I owe a reasonable transition to a new hosting solution and that reasonable transition will happen.

But for those of you who have some notion that my contribution to the community over the years creates an obligation to continue to contribute, to keep giving, to keep doing unpaid, community service for you, you're not living in reality.  The fact that I have given my time and my effort and my cheer leading and my coding and my writing and my servers and time I could be spending with my family (like the first day of my kids' first spring break that I missed because I had to ward off a DoS attack against scala-tools.org and keep the system running) and all of that stuff does not mean I am forever obligated to keep giving my time, my money, my efforts, and the other stuff that I've given in the past.

My life goal is to leave things better than I found them.  I feel a fierce obligation to that who have relied on me, and thus when I make transitions, I try to make them gracefully so that there's plenty of time for others to make those transitions.

When I made the decision in late May to do my next startup, http://visi.pro, in a language other than Scala and on a platform other than the JVM, I made sure to have a graceful transition of leadership in the Lift community and I continue to support Lift and the Lift community because I owe an obligation to those who adopted Lift.  

When it became clear that Josh and Derek were not going be able to continue to support scala-tools.org, I put out a call for more volunteers.  Given that I was phasing out of the Scala community, I could have just shut scala-tools.org down then.  But I asked for help and worked on a transition.

But now, now when it's clear that it's time to shut scala-tools.org down, there's plenty of "you should do this," "you should do that."  Well guys, where were you when I put out the call for help a few months ago?  What has changed that would make you capable of making scala-tools.org work now?

More importantly, what gives you the right to insult me personally for making a choice about something I own and something I contributed to mightily?  If you wonder why I'm sad about the state of the Scala community, just read my blog, watch my Scala Lift Off London keynote.

My way of working through my sadness about opportunities lost, my way of mourning these losses will be expressed on scala-tools.org.  I will use something I had a mighty hand in building to express sadness about what could have been.

Will this cause some inconvenience?  Maybe.  Will this raise awareness about the issues holding Scala adoption back in a way that I've been unable to do in other ways?  Maybe.  Is this my choice?  Yes.  Do I owe you more than a smooth transition to another domain and another provider?  No.  Do I owe you scala-tools.org?  No.

Permalink

]]> http://files.posterous.com/user_profile_pics/262685/dpp.gif http://posterous.com/users/36jxRzY3Z6x3 David Pollak David David Pollak Tue, 17 Jan 2012 12:26:00 -0800 Scala-tools.org winding down http://lift.la/scala-toolsorg-winding-down http://lift.la/scala-toolsorg-winding-down Scala-tools.org has been running for more than 3 years, providing Maven repository hosting to the Scala community.

Scala-tools.org was initially hosted on a machine that I owned and paid for and was co-administered by me and David Bernard.  In May, 2009, we transitioned the hardware to something more robust as well as having Derek Chen-Becker and Josh Sureth take over the administration tasks.  I still own the machine and pay for the hosting and bandwidth as well as organizing the administrators.

In the 2nd half of 2011, Josh and Derek got busy with family and new jobs and a whole bunch of other stuff.  Łukasz Kuczera and Indrajit Raychaudhuri volunteered to help out and were hoping for a transition from Josh and Derek.  The transition did not go smoothly.

While it's probably possible to dig through the configurations and such that Derek and Josh put together to figure out how to keep Scala-tools.org running, it's not in my heart to do it or to ask that others do lots of work on scala-tools.org.

The Scala community should be serviced by the company that is making money off the efforts of the Scala community, Typesafe, rather than a bunch of people contributing thousands of dollars a year of hardware and bandwidth and time to do something that could be done by the commercial Scala entity.

I owe a debt of gratitude to David B, Derek, Josh, Łukasz, and Indrajit for their efforts on behalf of the community.

In terms of scala-tools.org, the server will continue to run for a while.  If Nexus or Jenkins needs a restart, I'll do that sort of thing.  We will not be accepting any new hosting requests.  We will not provide service to folks if configurations get messed up or if they need changes to permissions, etc.  I expect that the server will continue to host artifacts until mid-June of 2012 (I'm going on vacation in mid-June and will have spotty IP connectivity, so I can't be around to fix things.)  This should provide a reasonable period for projects to find new hosting.

Thanks.

David

Permalink

]]> http://files.posterous.com/user_profile_pics/262685/dpp.gif http://posterous.com/users/36jxRzY3Z6x3 David Pollak David David Pollak Thu, 12 Jan 2012 11:40:46 -0800 Announcing Lift 2.4 Final http://lift.la/announcing-lift-24-final http://lift.la/announcing-lift-24-final The Lift team proudly announces the availability of the final release of Lift version 2.4.

Lift is a powerful, secure and most matured web framework available today. There are Seven Things that distinguish Lift from other web frameworks.

Lift applications are:

  • Secure – Lift apps are resistant to common vulnerabilities including many of the OWASP Top 10
  • Developer centric – Lift apps are fast to build, concise and easy to maintain
  • Scalable – Lift apps are high performance and scale in the real world to handle insane traffic levels
  • Interactive like a desktop app – Lift's Comet and Ajax support are super-easy and very secure

Read an overview of how Lift achieves these important goals.

Lift open source software licensed under an Apache 2.0 license.

Lift 2.4 includes the following new features and enhancements:

  • Lots of enhancements to JSON support
  • Record improvments
  • Squeryl/Record support for Crudify
  • Singificant enhancement to MongoDB support (including better support for reference records and binary fields)
  • Support for BsonDSL (BSON types to JsonDSL)
  • Significant enhancements to Mailer functionality
  • Significant enhancements to the CSS Selector transformers
  • Enhancements to Snippet resolution like sub-packages based resolution, Loc-based snippet resolution of Screen and Wizard, etc.
  • Significant improvement to REST support including stateless Async/Continuations on Jetty 7, Jetty 8 and Tomcat/Glassfish
  • Ability to get html5 compliant templates using data-lift attribute
  • Numerous localization modules
A complete list of changes are available for all the preceding milestones here:

Please join the Lift Community and enjoy building awesome apps with Lift.


Thank you, enjoy Lift!
- The Lift Team

Permalink

]]> http://files.posterous.com/user_profile_pics/1583881/profile-alt.JPG http://posterous.com/users/5egV2ijzBWNP Indrajit Raychaudhuri indrajitr Indrajit Raychaudhuri Wed, 21 Dec 2011 21:49:00 -0800 Announcing Lift 2.4-RC1 http://lift.la/announcing-lift-24-rc1 http://lift.la/announcing-lift-24-rc1

The Lift team is excited to announce the availability of Lift 2.4-RC1.

Bug fixes since Lift 2.4-M5 are listed here.

We are getting real close now. All going well, this would be the last RC before Lift 2.4 final. If your project depends on 2.4, test things out and report your observation to the mailing list.

Enjoy coding with Lift.

Thank you, Merry Christmas!
- The Lift Team

 

Permalink

]]> http://files.posterous.com/user_profile_pics/1583881/profile-alt.JPG http://posterous.com/users/5egV2ijzBWNP Indrajit Raychaudhuri indrajitr Indrajit Raychaudhuri Wed, 07 Dec 2011 09:53:51 -0800 Scala's version fragility make the Enterprise argument near impossible http://lift.la/scalas-version-fragility-make-the-enterprise http://lift.la/scalas-version-fragility-make-the-enterprise I have been working with Scala for more than five years.  In those five years, I've seen Scala evolve and seen the ecosystem and community evolve.

An attribute of Scala is that the Scala compiler generates fragile byte-code.  This means that all the code in an executable (JAR or WAR) must be compiled with the same library and compiler versions.  If you're using Scala 2.9.1 in your project, you must compile against a version of Lift that's compiled against Scala 2.9.1 and all the Lift dependencies must also be compiled against that version of Scala.  This is a reason that Lift has precious few Scala library dependencies.  It's also a reason that Lift is sprawling... there are a lot of modules in Lift that need to be cross-compiled and rather than having an external ecosystem of modules, we need to make them part of Lift to make sure they are all compiled against all the versions of Scala that Lift supports.

The by-product of this issue is that it's nearly impossible to test Lift or a Lift-based app against a pre-release of Scala.  This is one of the many reasons that there's almost always a "critical bug fix" release of Scala a few weeks after any major release.  The first chance that the broader community gets to use the ecosystem of Scala libraries and frameworks is after a release and after the cascading compilation/test/release 

A year+ back, during the 2.8 development cycle, some of us got together on the "Fresh Scala" project.  Basically, the idea was to have continuous integration of the major libraries in Scala-land and weekly milestones so that the community and the ecosystem could give better feedback on new versions of Scala.  Due to a lack of volunteer time, we never got the CI system built and here we are a year and a half later with the same Scala version fragility issues, but one thing has changed.

Scala is no longer exclusively an academic and community effort.  Scala the language and some associated libraries are now part of an enterprise-targeted suite from TypeSafe.  TypeSafe is a huge (20+ heads) venture funded company that is supposed to be bringing Scala to the enterprise.  But Scala's version fragility creates two huge costs for complex enterprise-type systems:
  1. All dependencies must be compiled against the exact same version of Scala and every referenced Scala library which makes in-house builds when there are multiple teams amazingly complex or time-consuming
  2. External libraries (like Lift) cannot have multiple layers of dependencies because you need to match the exact version of every library and Scala version all the way down
So, if you're in an organization with more than 2 or 3 development teams that are all generating internal Scala code, you can generally agree on the version of Scala and the various libraries that you're going to use.  When a new version of Scala or the libraries are released, you can get a couple of people in a room and choose to upgrade (or not.)  But once you get get past 3 teams, the coordination efforts become significant.  Trying to get 10 different teams to coordinate versions of Scala and Lift and ScalaZ and Rogue and Dispatch, etc. is going to be a significant cost.

As a library builder, the version fragility issue means that our library is not nearly as good as it could be and we can't service our community the way we want.

In terms of servicing the community, we cannot have predictable releases of Lift because we try to time our releases such that Lift will be released soon after a new version of Scala is released.  Given that Scala release schedules are not predictable and given that we need to wait for the dependencies (e.g., ScalaCheck and Specs) to be upgraded, we can't answer simple questions like "when will Lift support Scala 2.8.2?"

More importantly, there are few external Lift modules and they are generally not available except for specific versions of Scala and Lift and there are always issues when there's a version mismatch.  Modules like Rogue and Reactive Web are available for a small subset of Lift/Scala version combinations.  There are dozens of folks who have smaller modules for Lift, but none of them are cross compiled for the last year's worth of Scala and Lift releases.  This basically means you can use Rogue (something I'd suggest) or you can use Reactive Web (something else I'd suggest), but you can't use them in the same project because there's no guarantee that they are compiled against the same versions of Lift and Scala, nor is there any guarantee that they will be compiled against the versions of Scala and Lift that you want to use.

So, the Scala library and framework ecosystem is about as big as it can get given the Scala version fragility issue.  Because its not possible to have multiple layers of library dependencies in Scala, there will either be monolithic projects like Lift or islands of projects like ScalaZ.  And at this point, Scala does not have enough native libraries and frameworks to make it enterprise-worthy.  Yes, you can use Java libraries, but as others have found, the cost of wrapping Java libraries in Scala is often not worth the cost/effort.

What have I done about the issue?  Over the years, I've raised the issue privately and it has not been addressed.  I have tried to organize a project to address part of the issue, but haven't had the volunteer uptake for the project.  I have had discussions with Paul Phillips about what could be done and Paul, Jevgeni and I even worked out a system that could be integrated into the Scala compiler to address the issue in 2010 when we were at the JVM Language Summit.  The best answer so far is the Migration Manager, a closed source tool that may address some of the issues (I haven't tested it because I'm not going to use any non-OSS software for compiling or testing Lift to avoid any legal issues.)

What we need:
  1. We need something like Scala Fresh so that there's continuous integration across the major (and not-so-major) libraries and frameworks in the Scala ecosystem
  2. Something baked into the Scala compiler that makes the version fragility issue go away
What you can do:
  1. Blog about the issue and raise awareness about the version fragility issue and how it has impacted you
  2. Next time you're on a TypeSafe "what would you pay us money for?" call, please tell them that a vibrant Scala ecosystem is critical to wider adoption and the version fragility issue is significantly impacting both internal development efforts and ecosystem growth.  In order for your company to consider buying anything commercial from TypeSafe, you need broader internal adoption of Scala and that comes from reducing the transaction costs of using Scala including eliminating the version fragility issue in the open source parts of Scala.
Why am I writing this post today?  The version fragility issue has come up a bunch of times on the Lift list and the Lift committers list in the last week.  It's a non-trivial piece of pain and rather than being "go with the flow" about it, I figured I'd write about it and let folks know that it's pain and it's pain that could go away.

Permalink

]]> http://files.posterous.com/user_profile_pics/262685/dpp.gif http://posterous.com/users/36jxRzY3Z6x3 David Pollak David David Pollak Wed, 23 Nov 2011 22:23:26 -0800 A Huge Thanks to Seaside http://lift.la/a-huge-thanks-to-seaside http://lift.la/a-huge-thanks-to-seaside It was a little more than 5 years ago when I was searching around for a post-Rails web framework that I spent some quality time with Seaside.

Seaside is a Smalltalk-based web framework that provides power and simplicity by maintaining state on the server.  Web apps in Seaside are a continuation of a calculation.  Answers provided by submissions of forms allow the computation to continue.

I did a few months of work in Seaside and was working on adding Ajax to Seaside.  However, deploying a Squeak virtual machine and living my life in a Smalltalk VM were sufficient barriers that I went looking for something "more normal" for me.

However, the few months I spent with Seaside was tremendously influential in the way I approached web frameworks.  You can see echoes of Seaside in Lift's CometActor's ask/answer paradigm (the ask/answer thing even made it to Goat Rodeo.)

Seaside uses GUIDs on the client to mark state on the server.  This simple concept is bedrock on Lift and has served Lift very well in terms of allowing developers to express complex, interactive apps very simply.  The bedrock of GUIDs also leads to much of Lift's security.

So, this Thanksgiving, I'd like to give thanks to Seaside and Avi Bryant for inspiration and a template of excellence.

Permalink

]]> http://files.posterous.com/user_profile_pics/262685/dpp.gif http://posterous.com/users/36jxRzY3Z6x3 David Pollak David David Pollak Thu, 17 Nov 2011 10:06:00 -0800 It was 20 years ago today... http://lift.la/it-was-20-years-ago-today http://lift.la/it-was-20-years-ago-today

It was 20 years ago today that I embarked on an epic computer journey that defined my life as a coder and a business-person.  On November 17th, 1991, I laid down the first lines of code for the Mesa spreadsheet.

 

Mesa was a spreadsheet for NextStep and continues (without my help) to be a spreadsheet for OS X (which is the updated version of NextStep.) At the time I started coding Mesa, the spreadsheet category on NextStep was surprisingly crowded with an entry from Lotus, the amazing, but non-traditional Improv, and WingZ from Informix.  Additionally, a venture funded company was working on traditional, native NextStep spreadsheet called PowerStep.

 

I built a company, Athena Design, while building Mesa.  We launched Mesa in August 1992 and within 6 months, Mesa was the dominant spreadsheet in the NextStep market.  While some called me a Lone Wolf, in fact Athena and Mesa were an amazing collaboration by a stellar team.  Put another way, I built Mesa and Athena with a little help from my friends (at this point, please start listening to the Beatles Sgt. Pepper’s)

 

What was amazing about Mesa was we built it based on talking to spreadsheet users in the NextStep community.  NextStep sold heavily into financial services and those folks wanted to be able to tick real time data from Reuters and other data feed services, perform calculations, and trigger external events.  Mesa did this.  In fact, working with IBM and Reuters in the late 1990s, I discovered that Mesa was the original art for the “Real Time Spreadsheet.”  Additionally, Mesa was an early example of a spreadsheet component that could be embedded in other applications (maybe it was the first, although my friend Debby Meredith apparently wrote a Smalltalk spreadsheet that could be embedded as well.)

 

While the Next, and subsequent OS/2, OpenDoc, Taligent, and Be markets were not large enough to support a growing company, what Mesa represented was that a small team of amazing people who listened to users and mixed in some of their own vision could fundamentally change the landscape.

 

Five years ago, when I discovered Scala and started coding Lift, I made the decision, once again to eschew the status quo of MVC and, instead, learn from what users and developers need.  For the last 4 years, Lift has been the best web platform for building Comet, Ajax, and Secure web apps.  Lift has grown and evolved, yet the core decisions about how Lift worked have remained correct and solid, and users like Foursquare and the Guardian agree.

 

Modeling Lift and Mesa on user-needs rather than machine needs is a different approach.  It’s an approach that centers the product on the user rather than the machine.  Sometimes the difference is subtle and sometimes it’s not, but in the end, and  as Kernighan and Ritchie taught us, people time will always get more valuable and computing cycles will always get cheaper.

 

Now, today, 20 years to the day after I started my epic journey, I am launching into a new journey: Visi.Pro.

 

Visi.Pro brings Cloud Computing to the rest of us.  Visi.Pro is HyperCard for the iPad.  Visi.Pro lets users build iPad/iPhone apps on the iPad (or Mac) and deploy them seamlessly across the Cloud including using Cloud resources such as persistence, data sources and data sinks.

 

Visi.Pro provides a complete environment from language to IDE to run-time to data/app/component emporium.  Visi.Pro provides a complete environment for the rest of us to create interactive, powerful apps.  A video of the vision, a vision statement, and more can be found at http://visi.pro.

 

Building Lift and the Lift community, I have realized that standing on the shoulders of giants is the best way to build something world-changing.  The best giants around as the folks who make up the open source world and a substantial portion of Visi.Pro including the language and much of the iPad code will be open source under an MPL license.  This means that if others want to build stuff off the Visi language, a language so simple and powerful that any Excel or PHP developer will be at home with it, they are welcome and encouraged to do so.  You can check out more about the language and such at http://visi.io Please check out the code and the community... please contribute back to the conversation and the code.

 

Building Visi.Pro and Visi.io will be a long, tough learning process.  It’s going to be interesting to learn from the PHP and Excel users in the world.  It’s going to be great understanding the kinds of things business people and moms and teachers want to build on the iPad.  It’s going to be like skiing double-diamond black slopes to build an invisible type system into Visi so that the users are always guided to do the right thing.  It’s going to be spectacular to get the Program Language Theorists to work through a type algebra (yes, Visi will allow an algebra in the type system) along side a teacher describing a grading app.  But what will really generate a tsunami of joy is when people are able to build amazing, interactive, real-time, cloud-backed apps on their iPad.  I can’t wait for that day and I know it’s going to be a long, tough, and spectacularly rewarding journey for all involved!

 

Before I ask you to join me on this journey... before I ask you to join the Visi conversation, I want to talk about some changes in me and how this will impact the Lift community.

 

For most of my career, I have aligned myself with the dark horses and the lost kittens.  I bet on an ousted Steve Jobs and his Next platform.  I bet on OS/2 and OpenDoc when Windows was a better choice.  I bet on Jean-Louis Gassée and BeOS because he told great stories about RepoDepo.  I bet on Java and WebLogic in 1996.  I bet on Scala.  Some of those amazingly risky bets worked out and others, well, didn’t.  This time, I’m betting on the clear winner.  It’s clear that iOS will dominate the OS/computing landscape for the next generation.  It’s clear that the cloud and interconnected and partially connected computing will be the way it’s done for the rest of my professional life.

 

So, rather than choosing the dark horse, I’m going to bet on the winner.  And rather than choosing an existing category and simply building the best technology for that category, I’m going to create a new category (or more properly revive a lost category... the category of “everyone can program this machine and make it beautiful” category.)  I’m going to fundamentally change the way people program for the iPad and the Cloud. I’m going to kick a dent in the universe.

 

My commitment to Lift remains.  I love Lift.  I love the Lift community.  I remain in awe of the amazing committers.  I am stunned and amazed by the folks who have committed to using Lift and I remain committed to Lift and the folks who have adopted Lift.  For most of 2011, I have spent about 12 hours a week in the Lift community... working on the mailing list and closing tickets.  Most of this year, I’ve been doing Lift-related consulting and much of my contributions to the Lift code-base has been for my clients.  I will continue to spend 12 hours average a week in the Lift community.  What is going to change is that the tickets I close, the code I write for Lift, is going to be entirely community-focused.  It’s going to be based on what the community needs rather than what my clients need.  Longer term, I will find a way to make Visi and Lift play together.  They are both my children and I love them... although sometimes newborns need a little more attention than 5 year-olds.  The key change is that I will not be available to consult on Lift-related projects in the future.

 

So... what do I want from you?  

 

I want your brains.  I want your input.  I want your language ideas.  I want your app ideas.

 

Are you involved with Rust, Roy, Haskell or other amazing languages?  Have you built stellar iPad apps like Codea and Blueprint?  Please join the conversation.  We can share ideas and together be more than the sum of our individual parts.

 

Are you someone who wants to build something on your iPad?  Something beautiful and amazing?  Something that you can share via the cloud with others in real-time?  Something that sucks data from SalesForce, Twitter or a million other data sources or sinks on the Internet?  Please join the conversation.

 

Visi.Pro is going to be a totally epic journey and I look forward to you joining the team and making Visi.Pro life-changing for millions of iPad users.

 

Thanks!

 

PS -- Visi.Pro and Visi will always be defined, developed and built with strict adherence to Apple’s policies about what it allows on the App Store and on the iOS.  Visi.Pro, like the amazing Codea or Numbers, is a development environment and interpreted runtime.  I welcome any public or private (at Apple’s option) conversation with Apple regarding Visi.Pro to clarify the iOS and App Store rules and to insure that what we do with Visi.Pro is done clearly on the correct side of the line and with Apple’s happy blessing because, at the end of the day, our goal is to empower iPad and iOS users to rock their respective worlds!

Permalink

]]> http://files.posterous.com/user_profile_pics/262685/dpp.gif http://posterous.com/users/36jxRzY3Z6x3 David Pollak David David Pollak Thu, 10 Nov 2011 08:42:00 -0800 Announcing Lift 2.4-M5 http://lift.la/announcing-lift-24-m5 http://lift.la/announcing-lift-24-m5

The Lift team is excited to announce the availability of Lift 2.4-M5 (Milestone 5).

Quite a few enhancements and bug fixes have been added since Lift 2.4-M4 for this release.

Lift 2.4-M5 would be the last milestone before 2.4 final release. If your project depends on 2.4, now is the time to test things even more rigorously.

And, as usual, join the Lift community and enjoy coding with Lift.

Thank you, have fun!
- The Lift Team

Permalink

]]> http://files.posterous.com/user_profile_pics/1583881/profile-alt.JPG http://posterous.com/users/5egV2ijzBWNP Indrajit Raychaudhuri indrajitr Indrajit Raychaudhuri Tue, 20 Sep 2011 14:28:37 -0700 Grip goes live with Lift http://lift.la/grip-goes-live-with-lift http://lift.la/grip-goes-live-with-lift Grip is live with their systems built on the Lift web framework.  Grip is a financial decision support tool that enables financial institutions of all sizes to brand and offer an app that provides the most sought after mobile services. It aggregates consumers' balance and transaction data from unlimited number of domestic financial institutions into a single, up-to-the-minute collective view, empowering them to understand their money flow simply and without clutter. With no core integration, no set-up fee, no annual fee and no minimum user agreement, Grip simply cost the financial institution .99 cents per active user, per month.

It's very exciting to see more companies basing their business on Lift... especially companies from Iowa.

Permalink

]]> http://files.posterous.com/user_profile_pics/262685/dpp.gif http://posterous.com/users/36jxRzY3Z6x3 David Pollak David David Pollak Fri, 09 Sep 2011 13:32:18 -0700 Different ∙ Real ∙ Awesome -- Scala Lift Off London 2011 http://lift.la/different-real-awesome-scala-lift-off-london http://lift.la/different-real-awesome-scala-lift-off-london I'm very excited to announce the Scala Lift Off London 2011 on October 13th and 14th at Skills Matter in London!

The theme for this year's show is: Different ∙ Real ∙ Awesome

Scala and Lift are fundamentally different approaches to language and web framework. Scala and Lift are used in real projects and lead to real, measurable success.  Scala and Lift lead to awesome results and awesome happiness on the part of developers.  This year's Scala Lift Off will celebrate how Scala and Lift are Different ∙ Real ∙ Awesome.

Scala and Lift provide a different and better way to build complex, real-time, scalable, concurrent systems.

Wicked exciting to me is that Jon Pretty has agreed to do a keynote and discuss the Rapture Platform as a Service offering that his company has been building.  Jon has been in the Scala community for longer than I have and helped me learn Scala.  Rapture's different approach to PaaS is informed by Scala.  Rapture's benefits are real and measurable.  But most importantly, Rapture's holistic approach is awesome (don't believe me, come see for yourself.)

I will be giving a keynote, my first in the 4th year of Scala Lift Offs.  I'll explore the history and trajectory of Scala and Lift through the lens of, you guessed it, Different ∙ Real ∙ Awesome.

This year's Scala Lift Off will be a blend of open spaces and prepared presentations.

The morning will include two tracks, one Lift focused and one Scala-oriented.  I'm working with Andy Hicks and Kevin Wright to find awesome presentations for the two tracks.  If you're interested in presenting, please ping me, Andy or Kevin.

The afternoon will be an open space format.  This will allow attendees to ask for or offer presentations and generally leads to excellent discussions.  Sometimes, the discussions are a few people and sometimes they are among dozens or more.  Skills Matter's facilities have a ton of great spaces that enable small to large groups to engage in terrific dialogs.

If you're a member of the European Scala or Lift communities, the Scala Lift Off London offers you an excellent opportunity to meet and interact with the folks you've been working with for years on mailing lists.  The Scala Lift Off also gives you a chance to share your experiences with Scala and/or Lift as well as influence the direction of the language as well as the libraries, tools, and frameworks in the Scala ecosystem.

If you're interested in learning more about Scala or Lift, the Scala Lift Off is the ideal place to ask questions and get them answered by a wide variety of real-world users as well as language and framework designers.  If you're in sports better, trading/financial services, social media, or other industries that focus on real-time, big-data, Scala and/or Lift offer you differences worth learning about.  See why the likes of Twitter, Foursquare, The Guardian, and others have found real business-changing awesomeness in the differences that Scala and/or Lift offer.

Space at the conference is limited and the Scala Lift Off London was full last year.  Purchase your tickets today.  Watch this blog for updates and more agenda items as they become available.

Permalink

]]> http://files.posterous.com/user_profile_pics/262685/dpp.gif http://posterous.com/users/36jxRzY3Z6x3 David Pollak David David Pollak Thu, 08 Sep 2011 06:49:41 -0700 Announcing Lift 2.4-M4 http://lift.la/announcing-lift-24-m4 http://lift.la/announcing-lift-24-m4
The Lift team is excited to announce the availability of Lift 2.4-M4 (Milestone 4).

Lift 2.4-M4 is the first milestone to supports Scala 2.9.1 including the older 2.9.x and 2.8.x releases.

The team added about 20 enhancements or bug fixes since Lift 2.4-M3.

Please join the Lift community and enjoy the benefits of coding with Lift.

Thank you, have fun!
- The Lift Team

Permalink

]]> http://files.posterous.com/user_profile_pics/1583881/profile-alt.JPG http://posterous.com/users/5egV2ijzBWNP Indrajit Raychaudhuri indrajitr Indrajit Raychaudhuri Thu, 01 Sep 2011 08:54:28 -0700 Please join me for 3 days in London! http://lift.la/please-join-me-for-3-days-in-london http://lift.la/please-join-me-for-3-days-in-london I'm doing a three day course September 14-16 at Skills Matter in London.

The first day of the course will be the standard Simply Lift stuff... basically it's getting started with Lift.

The next two days, though, I hope will be magic.  The idea of spending a couple of days face-to-face, hands-to-keyboard with a small number of people is very exciting to me.

One of the greatest joys for me is to work with people as they learn Lift and see how they approach problem solving.  While the Lift mailing list is a great place to watch how people approach Lift, there's no substitute for doing it face to face with the high bandwidth communications channel called reality.

I am looking forward to working with a small group of people to learn what challenges they face building web apps and how they can use Lift as it stands today to make that process easier.  But more importantly, how we can improve Lift to meet the challenges of our end users.

So, if you join me, you will learn Lift, get lots of one-on-one time with me, and I promise to add features to Lift in real time to make your web app building easier and better.

I am really looking forward to it!

Permalink

]]> http://files.posterous.com/user_profile_pics/262685/dpp.gif http://posterous.com/users/36jxRzY3Z6x3 David Pollak David David Pollak Thu, 21 Jul 2011 08:29:00 -0700 Announcing Lift 2.4-M3 http://lift.la/announcing-lift-24-m3 http://lift.la/announcing-lift-24-m3
The Lift team is excited to announce the availability of Lift 2.4-M3 (Milestone 3).

Lift 2.4-M3 supports Scala 2.8.x as well as 2.9.x.

The Lift team added over 20 enhancements or bug fixes since Lift 2.4-M2.

 Noteworthy breaking change:

As announced earlier, JavaMail dependency has been upgraded to 1.4.4 which is formally available from Java.net Maven 2 repository (and not from Maven central). As a result, existing applications would need to add the repository in the SBT project file as so:

lazy val JavaNet = "Java.net Maven2 Repository" at "http://download.java.net/maven/2/"

Please join the 3000-member strong Lift community and enjoy the benefits of coding with Lift.

Thank you, have fun!
- The Lift Team

Permalink

]]> http://files.posterous.com/user_profile_pics/1583881/profile-alt.JPG http://posterous.com/users/5egV2ijzBWNP Indrajit Raychaudhuri indrajitr Indrajit Raychaudhuri Thu, 07 Jul 2011 15:05:19 -0700 Lift and Data Driven Comet http://lift.la/lift-and-data-driven-comet http://lift.la/lift-and-data-driven-comet Daniel Spiewak is one a rant again about Lift's Comet model being the wrong one and being the devil and such.  He's had this rant in the past and I've tried to talk him through the positive of what he does want.  I've been unable to understand why his goal isn't served by what's already in Lift's Comet support.  What the discussion usually boils down to is "in most of the Lift Comet examples, the server manipulates client DOM, but the server should know/care about client state."  I agree with that, but the fact that example code manipulates client DOM doesn't mean that this is the only way to work with Lift's Comet.  Further, complaining about the examples rather than discussing positive use cases doesn't help me or the Lift team better understand how to build better data-driven (rather than DOM driven) examples and abstractions.  With that off my chest, let me walk through Lift's Comet and how one can build data driven Comet apps based on available examples as well as some conceptual discussions about what I've done in non-open source projects.


Let's take a quick tour of Comet and what Lift's Comet implementation offers.  HTTP is a client-owned protocol.  The client in HTTP makes a request on a server.  Based on that request, the server returns a response.  After the server has returned the response, the server has no further mechanism for changing state on the client.


It's valuable to have applications that allow server state to be "pushed" to the client.  These applications include stock quote applications, sports betting, multi-user games, etc.  Comet, or server push, is a mechanism for the browser to keep an HTTP connection open to the server and when server state changes in a way that may impact the client, the server sends data over the connection to the client and the client processes the chunk of data.


There are a fair number of "elegant engineering solutions" to keeping the HTTP connection open so that the server can "push" new information to the client. 


Lift's current Comet implementation uses long polling.  In the future, Lift will also use WebSockets, but the WebSocket API and implementation isn't "baked" yet, and Lift's current implementation works well for browsers from IE6 on.  Lift's long polling implementation opens a single HTTP connection from the browser to the server if one or more Comet components are detected on a HTML page.  The request contains a list of the components and the "version" for each of the components.  If the version number of any of the components on the server is "newer" than the version on the client, the deltas are sent as the response, the connect is closed, the browser applies the deltas and then re-opens the HTTP connection (with HTTP 1.1 keep-alive this does not imply reopening a TCP/IP connection.)  If the version of the component changes while the HTTP "poll" is open, the deltas are sent down as a response and the connection is closed.  If no state changes after 110 seconds (this is a tunable parameter), a noop is sent to the browser and the browser re-opens the HTTP connection.  The 110 second timeout is to insure that Lift's comet implementation is proxy friendly.


Lift's comet implementation is hidden from the developer.  The developer need only focus on two things:

  1. Generating "initial state" that is sent from the server to the browser during a full page load that contains a Comet component
  2. When state changes on the server (state can only change for the CometActor is it receives an asynchronous message in its Actor mailbox), the server generates JavaScript that causes the browser to take appropriate action based on the server state change.  Not all state changes on the server necessarily result in state changes on the client.  Further, this does not imply that the server must keep track of or keep a mirror of client state.

The mechanism for achieving #1 above is implementing the render and fixedRender methods in a CometActor.  The former is required and the latter is optional.  The combination of the return values of these two methods define initial state for the CometActor during a full page load.  Here's the documentation for render:
  /**
   * It's the main method to override, to define what is rendered by the CometActor
   *
   * There are implicit conversions for a bunch of stuff to
   * RenderOut (including NodeSeq).  Thus, if you don't declare the return
   * turn to be something other than RenderOut and return something that's
   * coersable into RenderOut, the compiler "does the right thing"(tm) for you.
   * <br/>
   * There are implicit conversions for NodeSeq, so you can return a pile of
   * XML right here.  There's an implicit conversion for NodeSeq => NodeSeq,
   * so you can return a function (e.g., a CssBindFunc) that will convert
   * the defaultHtml to the correct output.  There's an implicit conversion
   * from JsCmd, so you can return a pile of JavaScript that'll be shipped
   * to the browser.
   */
  def render: RenderOut

You can define your render method to be DOM oriented.  Here's the super duper simple code for a Comet-based Chat app where the Server defines the DOM:

/**
 * The comet chat component
 */
class Chat extends CometActor with CometListener {
  private var msgs: Vector[String] = Vector() // private state
 
  // register this component
  def registerWith = ChatServer
 
  // listen for messages
  override def lowPriority = {
    case v: Vector[String] => msgs = v; reRender()
  }
 
  // render the component
  def render = "li *" #> msgs
}

This example demonstrates how easy it is to write a Lift Comet component.  It is not and full, industrial strength implementation of a Chat component.  It is an example that strips the code down to its bear essence.  The essence is "set up default state, when change comes in, change complete state and redraw the entire screen real estate associated with the component to reflect the new state."


However, we could just as easily have done an entirely data driven application.  This is taken from the Frothy example that integrates Lift and Cappuccino:

class Clock extends CometActor {   override def localSetup() {     super.localSetup()     ActorPing.schedule(this, 'Ping , 3 seconds)   }  override def highPriority = {     case 'Ping =>      partialUpdate(currentTime)       ActorPing.schedule(this, 'Ping , 3 seconds)   }  def currentTime: JsCmd = JsRaw("clockCallback("+(""+now).encJs+");")   def render = {     val str: String = """var f = function() {try {"""+(currentTime.toJsCmd)+"""} catch (e) {setTimeout(f, 50);}}; f();"""     OnLoad(JsRaw(str))   }}

In this example, the server side knows nothing about the client state.  The server side sends events to the client and those events call a client side function with event data.  The server-side knows nothing about the client state, browser DOM or anything else.  It's up to the client side to implement the the function.


More generically, the above could be written as:

class KnowNothing extends CometActor {
  def render = Noop // we have no comment on initial component state

  override def lowPriority = {
    case msg: MyMessage => partialUpdate(callEventHandler(jsonSerialize(msg)))
  }

  def callEventHandler(in: JObject): JsCmd = // what function do we call on the client side with a JSON blob?
  def jsonSerialize(in: MyMessage): JObject = // serialize a case class
}

And voila... we've got a comet component that simply passes events from the server to the client.  The Comet component has no knowledge or information about client state.  This is in effect an "Actor proxy" between the server and the client.  What you get is an implementation that passes messages from server to client.


"What benefit do I get by using the event passing mechanism?" you may ask.  Lift's Comet implementation multiplexes all the Comet components on a page through a single HTTP connection.  So, you could have 20 or 50 or more event handlers in the browser all handling different parts of the screen and Lift will handle all those components through a single connection.  If there are 10 updates between HTTP requests, all those updates will go down the same response.  If the client is disconnected for a period of time (a mobile user is on a train going through a tunnel where there's no Internet connectivity), the client will receive all the deltas in order when the client is once again reconnected (note there are certain limits that are tunable as to the amount of time and aggregate number per comet component of deltas that are retained.)


So, we've shown both ends of the "server knows everything about client state" and "server knows nothing about client state" spectrum.


I've written substantial Lift comet code for Innovation Games and Much4.


In Much4, the CometActor in the server kept the authoritative copy of the data.  When updates can in the data deltas were calculated and JavaScript that updated the client's representation of the data to match the server's version of the data was sent to the client via partialUpdate along with a command to "redraw" the client.  The client redrawing was accomplished entirely in JavaScript on the client... the updated DOM was generated entirely by client-side JavaScript.  Thus, the state that the server knew about the client was the state of the data on the client.  The CometActor on the server knew nothing about the DOM state on the client.


In the Buy a Feature game in Innovation Games, the CometActor on the server kept a copy of the DOM of the gameboard.  The server was authoritative about the client's data state and DOM state.  In fact, the client kept no state other than the DOM.  Changes to gameboard state were calculated by generating deltas between state and time T and state at time T+1 and those changes were turned into DOM manipulation JavaScript that was aggregated and send to the client via partialUpdate.  Because of the rules of gameplay, there was never a case where the places that the user was changing on the gameboard would be updated without the server knowing the deltas.


In the Prune the Product Tree game, the gameplay took place on an SVG canvas for "modern" browsers and some wacky something something in IE6.  The server never had any knowledge about the way that the gameboard was being displayed.  In this instance, we kept with the gameboard delta mechanism, but the deltaing generated two pieces of JavaScript for each delta between gameboard at T and gameboard at T+1.  One of those deltas was the JavaScript necessary to update the browser-side data structure at that point in the node and the second was a call into the node-specific "update the visual display" routine (for example moveItem(itemID, oldPosX, oldPosY, newPosX, newPosY)).  In this case, the deltaing routine had to have knowledge of the API structure on the client.  This was for expediency sake... it was easier to write Scala code that knew about the client APIs than write JavaScript that could take the delta commands and also forward them to the redrawing commands.  In this case, the server knew what client data state should be and generated commands to send the data down.  Note, too, that the client was "smart enough" not to cause data changes if (1) the the browser already contained the new state (this allowed for a single client to update its state without having to do a server round-trip) and (2) not updating items that the user was "touching" until the user finished touching the item.


Lift's Comet support has been able to work effectively with the above wide range of scenarios.  The place where Lift's Comet support will not work as well is if you try to mix the metaphors of DOM state and data state when there's code in the browser that will modify the DOM state without telling the server.  In the case that you only want the server to be partially knowledgeable about DOM state, then you're opening a huge can of worms.  Yes, Lift lets you open that can of worms, but just because a web framework lets you make bad design decisions that's not the web framework's fault.


Yes, there are plenty of API improvements we could make for data-driven Lift Comet.  I'd love to see a data diffing mechanism that'd take two JObjects and come out with JavaScript representing the commands needed to update the old to the new as well as generate the delta events.  We hand-wrote that mechanism in Prune the Product Tree... but having it automagic would be great.  Yep, it'd be better if there was more documentation and example code for doing data-driven Comet.  I'd love to get beyond the research phase on my Lift Comet to KnockoutJS integration as well as finishing the work I started doing Lift to SproutCore integration.  But a lot of that kind of stuff is community and client demand driven.


So, I thoroughly and completely disagree with the assertion that Lift's comet support requires that you keep state or DOM state in the Comet component.  Lift's Comet support gives the developer a wide variety of ways to send a wide variety of data from the server to the client based on events on the server.

Permalink

]]> http://files.posterous.com/user_profile_pics/262685/dpp.gif http://posterous.com/users/36jxRzY3Z6x3 David Pollak David David Pollak Wed, 06 Jul 2011 12:00:35 -0700 Web Framework Manifesto (republished from 2006) http://lift.la/web-framework-manifesto-republished-from-2006 http://lift.la/web-framework-manifesto-republished-from-2006

[Originally posted to my now defunct blog on November 21, 2006]



After touring a whole bunch of web frameworks, I've come to the conclusion that no existing framework satisfies the needs of a broad range of web developers. The existing web frameworks suffer from a wide variety of problems, conceptual and implementation-wise, that make way too much work for the web developer, the deployment guys, the folks who do application maintenance, and/or the end users. In this rant, I seek to define the criteria that a “good” web framework will meet.

The criteria for a good web framework:

  • A quick and easy way to map between a relational database and the target application. Rails' ActiveRecord is a really great example of how to map a relational database. Sure, you might want to use Magma with Squeak for true object persistence, but for most applications in most of the world, you've got a relational database on the back end and you've gotta map to it. The mapping should “do the right thing by default” and all the schema and class information should live in 1 or at most 2 (e.g., migrations and model class) places.

  • Easy, “right by default,” HTTP request mapping. A request comes in and gets routed to the right place. This is another place that Rails really shines (at least at the “page” level.) PHP and JSP also do well here. Schemes (like Struts) that require 35 configuration files, etc. to say “/foo/bar/33” gets routed to the Bar method on the Foo controller are way to complex. Seaside takes this to yet a better level... requests get mapped to the right closure in the right component. But I digress.

  • Automatic “view” selection and composition. Basically, the “right by default” view should be selected based on the request, but alternate views should be specified by the “controller.” Views should be CSS friendly. I'm split over having separate template files (e.g., Rails, JSP, etc.) or embedding the HTML in the file (e.g., Seaside) or having both options (Erlyweb.)

So far, I've described Rails. So far, I've described a system that works well for knocking together quick “CRUD” (create, read, update, delete) applications. If all you ever needed to do was spit out web pages that allowed managing rows in a database, all you would need was Rails. But there's so much more that's necessary.

  • Pages must be composed of arbitrary components that manage their own state. This means that the search panel, the scrolling “what's hot” area, the catalog, and the shopping cart are all separate components. Seaside really excels in this area. Check out the Seaside Sushi store demo that demonstrates many different components with different state all on the same page. Remember also, that the component nature of the page means that the components each receive their own UI messages. This is a place where Rails does not excel.

  • The rendering of components must be asynchronous based on user-based and external event-based state change. This means that if state changes in the component, the UI should be updated. Maybe it's updated the next time the page is reloaded (this is the way Seaside's Sushi store works,) the next time there's an AJAX request made, or via a Comet push. The components should be agnostic to the update mechanism. They should merely mark themselves as dirty and be re-rendered the next time there's an opportunity.

  • Components should be live (or seamlessly persisted) at all times, ready to respond to events.

  • The browser should be honored and feared. That means the back button should “do the right thing” (see Seaside) and input from the browser should never be trusted, but should always be tested, validated, and destroyed if it is unexpected (e.g., throw away a POST that contains parameters that were not in the form presented to the user.)

  • There should be a single way of describing input validation. That validation should happen whenever possible on the client, but should always be repeated on the server and before any model state is modified.

  • Mapping between object fields and HTML (or whatever the presentation layer is) should be “right by default” and should be extensible based on new technology. Rails and view helpers rule here.

  • There should exist an orthogonal security layer such that objects that are not accessible to a user should never be returned in a query for the user and fields on an object that are not accessible should not be visible. The security and access control rules should be algebraic and demonstrable during a security audit. This means that neither the view nor the controller should have to test for access control. Objects and requests should be sanitized before they get to the “controller.”

  • Code should be impervious to a replay attack. That means that fields in forms should have random names that change for each request.

  • There should exist a simple, unified way to describe modal user behavior (e.g., filling out a multi-page form.) Seaside rules in this respect.

  • Sessions should be tied to a browser window/tab, not to a browser session. Once again, Seaside really rules on this count.

  • The framework and runtime should correctly and gracefully deal with non-ASCII characters.

  • Deploying the web application should be as simple as putting a file in a known location (e.g., a WAR file on a J2EE server) or by executing a single command (e.g., Capistrano.)

  • Deployments should contain all dependencies such that as long as the target system meets a particular minimum specification (e.g., running Java 1.4 and Tomcat 5.5), the application will work without having to load other configuration files.

  • Deployment and management should be able to be done via command line or a web browser and should never require VNC or some other screen-cast or screen scraping.

  • Testing should be an integral part of the framework and should allow simulating HTTP requests. Rails has the best testing framework of any web development framework I've seen.

  • The production environment should support modern technology including executing multiple threads in a single process and allowing for many “live” objects to be corresident (an absolute necessity for Comet-style applications.)

  • The production environment should support hot code replacement such that new code can be placed in production without impairing existing user state.

  • The development environment should support hot code replacement such that once a file is saved, it becomes live at the next HTTP request. Sure, it may be compiled and moved to the app server on save (Eclipse does this with Java code) but the developer should not have to explicitly compile, restart, reload in order to test a change.

  • The system should be able to map input from a variety of different formats (SOAP, REST, SMTP, etc.) such that requests are normalized and responses are sent over the appropriate medium.

  • There should exist a mechanism for adding functionality to the system with few or no API calls. Rails Engines are an example of this.

  • Subsystems and added functionality should be defined by a clear interface that can be tested and validated during a compile or test cycle. Using parts of the subsystems that are not defined by the interface should be flagged during the test or compile cycle.

That's the list so far. I think it's doable with existing technology.

Rails (http://rubyonrails.com/) is awesome for CRUD, but becomes as hard as Java/JSP beyond the basic paradigm.

Seaside (http://seaside.st/) has the most innovative ideas and the best abstraction away from HTTP. However, Squeak as it currently exists and Cincom's pricing are barriers.

Erlyweb (http://erlyweb.org/) an Erlang-based, Rails-inspired framework has the best chance to deal with high volume Comet-style applications. The Erlang run-time is stable and supports a huge (hundreds of thousands) number of concurrent threads and has an amazing message passing mechanism.

Jifty (http://jifty.org/view/HomePage) is Rails on Perl... not a bad idea.

Django (http://www.djangoproject.com/) is a Python-based framework. I haven't used it, but many people love it. I have been unable to wrap my head around Python. Given how many people use and like Python, this seems to be a failure in my brain. Sorry I can't give better feedback about a tool that others find value in.

Aranea (http://www.araneaframework.org/) is a Java framework that barks up some of the same trees that Seaside does. However, without continuations (or at least syntactically pleasing continuations) I don't think a Java-based framework can support rapid, maintainable web sites.

Permalink

]]> http://files.posterous.com/user_profile_pics/262685/dpp.gif http://posterous.com/users/36jxRzY3Z6x3 David Pollak David David Pollak Mon, 06 Jun 2011 10:19:41 -0700 Lift 2.4-M1 is available http://lift.la/lift-24-m1-is-available http://lift.la/lift-24-m1-is-available

Lift is the most powerful, most secure web framework available today. There are Seven Things that distinguish Lift from other web frameworks. Lift applications are:

  • Secure -- Lift apps are resistant to common vulnerabilities including many of the OWASP Top 10
  • Developer centeric -- Lift apps are fast to build, concise and easy to maintain
  • Scalable -- Lift apps are high performance and scale in the real world to handle insane traffic levels
  • Interactive like a desktop app -- Lift's Comet support is unparalled and Lift's ajax support is super-easy and very secure
Sites powered by Lift include Foursquare, Novell Vibe, the UK Guardian, and Open Study.

The Lift team is excited to announce the availability of Lift 2.4-M1 (Milestone 1).

Lift 2.4-M1 supports Scala 2.9.0 and 2.9.0-1.

The Lift team added over 45 enhancements or bug fixes since Lift 2.3.  Notably:

  • Improvements to MongoDB support
  • Improvements to the already awesome lift-json package
  • Enhancements to tools for building complex forms
Lift's JSON, Util, Actor, and Common packages can be used independently from the Lift Web Framework.

Please join the Lift community and enjoy the benefits of coding with Lift.

Permalink

]]> http://files.posterous.com/user_profile_pics/262685/dpp.gif http://posterous.com/users/36jxRzY3Z6x3 David Pollak David David Pollak