Get the new bits here: http://popforums.codeplex.com/releases/view/60571
This is the second beta for the ASP.NET MVC3 version of POP Forums. Next step is a release candidate. It is considered feature complete, and ready for testing and feedback. For previous release notes, look here, here, here and here.
Check out the live preview: http://preview.popforums.com/Forums
Setup instructions are on the home page of this project.
What's new in beta two? Since the first beta:
- Avatars and images are resized on upload if they're too big
- Rich text box is turned off from profile, or if you view in a browser id'ing itself as mobile
- Edit posts, see that they've been edited
- Delete posts (soft)
- First post preview from topic lists
- Show edit/moderation history to mods
- Quoted replies
- User-to-user e-mail
- Admin: IP history
- Admin: Approve user photos
- Show IP's to mods
- Home page stats
- Decouple app start from global.asax
- Private messages (one-to-many)
- Admin: Mail all users (subscribed), with opt-out links
- Various bug fixes, style tweaks and refactoring
The app is running in production on MouseZoom
today, so it's being actively tested. With this testing, and your feedback, we'll put out a release candidate next. Between now and then:
- Refactor where it makes sense to reduce friction
- UI refinement where appropriate
- Explore potential for a setup thingy
- See if it's possible to really make it an atomic thing that can be NuGet-ed
So far, so good! This release brings it to feature parity with the crufty old Webforms version, in about half of the code. It's nice to be beyond science project status. The only thing really keeping me up at night is a desire to be able to split the app off with its own dependency injection, so you can easily roll with whatever DI container you'd like. Right now, if you want to use it in your MVC app, you pretty much have to use Ninject. While I dig it, it doesn't mean everyone does. If you've got any feedback or ideas about how to do it, I'd love to hear it in a discussion topic here on CodePlex.
As for a time line, I suspect that the RC isn't that far off. Stay tuned!
If you've never been to Mix, you're missing out on what is arguably one of the best conferences that Microsoft does. I'm not just saying that because I work here... I felt that way before, having been to most of them. The breadth of people and disciplines make it a really exciting event that pushes it well beyond the "Redmond bubble," as I like to call it. You should go.
In any case, there's an Open Source Fest happening the night before Mix starts, on Monday, from 6 to 9 p.m. There will be people there representing a ton of great projects, some as enormous as Umbraco, as well as people doing SDK's, controls and other neat stuff. Best of all, you get to vote for your favorites. Unless your favorite is Orchard, because Microsoft is sponsoring that directly. Or if it's POP Forums, not because Microsoft is sponsoring it, but because that's where I work in my day job. No prizes for me! Come by and say hello. I think the app will be nearly final by then, and it's already running on MouseZoom, one of my little side projects.
The quality and diversity of open source projects around the Microsoft stack just keeps getting better. Our platform is also pretty great at running stuff we don't make. This will be a pretty exciting Mix. Can't wait!
It has been a ton of work, interrupted over the last two years by
unemployment, moving, a baby, failing to sell houses and other life
events, but it's really exciting to see POP Forums v9
coming together. I'm not even sure when I decided to really commit to
it as an open source project, but working on the same team as the
CodePlex folks probably had something to do with it. Moving along the
roadmap I set for myself, the app is now running on a quasi-production
site... we launched MouseZoom last weekend. (That's a post-beta 1 build of the forum. There's also some nifty Silverlight DeepZoom goodness on that site.)
have to make a point to illustrate just how important starting over was
for me. I started this forum thing for my sites in old ASP more than
ten years ago. What a mess that stuff was, including SQL injection
vulnerabilities and all kinds of crap. It went to ASP.NET in 2002, but
even then, it felt a little too much like script. More than a year
later, in 2003, I did an honest to goodness rewrite. If you've been in
this business of writing code for any amount of time, you know how much
you hate what you wrote a month ago, so just imagine that with seven
years in between. The subsequent versions still carried a fair amount of
crap, and that's why I had to start over, to make a clean break. Mind
you, much of that crap is still running on some of my production sites
in a stable manner, but it's a pain in the ass to maintain.
So with that clean break, there is much that I have learned. These are a few of those lessons, in no particular order...
Avoid shiny object syndrome
the years, I've embraced new things without bothering to ask myself
why. I remember spending the better part of a year trying to adapt this
app to use the membership and profile API's in ASP.NET, just because
they were there. They didn't solve any known problem. Early on in this
version, I dabbled in exotic ORM's, even though I already had the
fundamental SQL that I knew worked. I bloated up the client side code
with all kinds of jQuery UI and plugins just because, and it got in the
way. All the new shiny can be distracting, and I've come to realize that
I've allowed it to be a distraction most of my professional life.
Just query what you need
spent a lot of time over-thinking how to query data. In the SQL world,
this means exotic joins, special caches, the read-update-commit loop of
ORM's, etc. There are times when you have to remind yourself that you
aren't Facebook, you'll never be Facebook, and that databases are in
fact intended to serve data. In a lot of projects, back in the day, I
used to have these big, rich data objects and pass them all over the
place, through various application tiers, when in reality, all I needed
was some ID from the entity. I try to be mindful of how many queries hit
the database on a given request, but I don't obsess over it. I just get
what I need.
Don't spend too much time worrying about your unit tests
you've looked at any of the tests for POP Forums, you might offer an
audible WTF. That's OK. There's a whole lot of mocking going on. In some
cases, it points out where you're doing too much, and that's good for
improving your design. In other cases it shows where your design sucks.
But the biggest trap of unit testing is that you worry it should be
prettier. That's a waste of time. When you write a test, in many cases
before the production code, the important part is that you're testing
the right thing. If you have to mock up a bunch of stuff to test the
outcome, so be it, but it's not wasted time. You're still doing up the
typical arrange-action-assert deal, and you'll be able to read that
later if you need to.
Get back to your HTTP roots
Webforms did a reasonably decent job at abstracting us away from the
stateless nature of the Web. A lot of people criticize it, but I think
it all worked pretty well. These days, with MVC, jQuery, REST services,
and what not, we've gone back to thinking about the wire. The nuts and
bolts passing between our Web browser and server matters. This doesn't
make things harder, in my opinion, it makes them easier. There is
something incredibly freeing about how we approach development of Web
apps now. HTTP is a really simple protocol, and the stuff we push
through it, in particular HTML and JSON, are pretty simple too. The
debugging points are really easy to trap and trace.
Premature optimization is premature
go back to the data thing for a moment. I've been known to look at a
particular action or use case and stress about the number of calls that
are made to the database. I'm not suggesting that it's a bad thing to
keep these in mind, but if you worry about it outside of the context of
the actual impact, you're wasting time. For example, I query the
database for last read times in a forum separately of the user and the
list of forums. The impact on performance barely exists. If I put it
under load, exceeding the kind of load I expect, it still barely has an
impact. Then consider it only counts for logged in users. The context of
this "inefficient" action is that it doesn't matter. Did I mention I
won't be Facebook?
Solve your own problems first
This is another trap I've fallen into. I've often thought about what other people might
need for some feature or aspect of the app. In other words, I was
willing to make design decisions based on non-existent data. How stupid
is that? When I decided to truly open source this thing, building for
myself first was a stated design goal. This app has to server the
audiences of CoasterBuzz,
MouseZoom and other sites first. In this development scenario, you
don't have access to mountains of usability studies or user focus
groups. You have to start with what you know.
I'm sure there are
other points I could make too. It has been a lot of fun to work on, and I
look forward to evolving the UI as time goes on. That's where I hope to
see more magic in the future.
If you've read my blog for any amount of time, you probably know that I tend to develop stuff in a Parallels VM on a Mac. It's how I roll. I like VM's because I can trash them and do really stupid things with beta software. That said, there is a pain point that doesn't seem that well documented when it comes to installing stuff in this scenario.
The WP7 tools, and SP1 for Visual Studio 2010 (perhaps only if you already have the WP7 tools installed, I'm not sure), do something strange on install. As if it weren't already a long and slow installation, for reasons I don't understand, the installer fires up an instance of Windows Phone Emulator. As you may already know, the emulator doesn't run in a VM, because it is itself a VM, apparently. What it will do is fire up your CPU, make your comprooder hot and make the fans blow harder.
I found this out accidentally, as I started the (slow) phone tool installation once, and walked away. An hour and a half later, I came back to find it hadn't finished. But it was hot and the CPU was pegged, so I fired up the task manager to find XDE.exe, the phone emulator, cranking away. I had to kill it several times, and eventually the install finished. It fired up just once in the SP1 install, but it still had the same hanging effect.
I can't for the life of me figure out why it does this. In a VM, I can connect the phone to it and use that, so I don't need the emulator. But this install, firing up the emulator, will make it choke until you kill the XDE.exe process. Watch out!