January 2007 - Posts
Obviously I missed the boat somewhere along the line. I realized today that I've never used FormsAuthentication in an ASP.NET v2.0 application before. As it turns out, it doesn't work the same as it used to.
Back in the old days of v1.x, you could call FormsAuthentication.SetAuthCookie(name, persist), then change its expiration date and make it last for a year. Just to make sure I wasn't crazy, I checked some of my old and yellowing v1.x books to make sure that this is what you did. I hope I didn't write that into my book, because the persistance part doesn't work anymore, or rather, doesn't work the same.
Sure, the cookie will be there, but the plumbing will consider it invalid once the session times out. As Scott mentions in a link from the comments, you can change the timeout, but this isn't exactly what I was going for since it creates a sliding expiration. I wanted a finite ending in 30 days.
This article on MSDN describes what you should do. I'm a little annoyed that this change happened without changing the interface, or rather adding a different one for the current behavior. Having some arbitrary sliding timeout is weird to me, and having a "persist cookie" value in SetAuthCookie implies that it's going to stick around until you tell it otherwise.
Of course, maybe I just feel really silly for not having been exposed to the change ages ago.
I've developed a strange problem. I'm using FormsAuthentication to login users. I persist the .ASPXAUTH cookie and set its expiration to today plus 30 days.
The cookie doesn't go anywhere, but the app stops recognizing it. I check it and, indeed, the cookie is still there with an expiration a month away. The only thing "exotic" that I can think of that I do is assign some roles to the principal, but I've done that before without consequence.
Like most developers, I work with other developers. Most are computer sciency and kick ass when it comes to class design and architecture. The problem with this is that this creates a UI design culture that is not always optimal.
There will always be bigger picture architectural design decisions that need to be made. So much of what we write code for doesn't even involve UI, especially since big systems are distributed and service-oriented. But when someone comes to you with something from a competitor site, and says, "I want to do this," starting somewhere deep in the application is the wrong place to go.
It's pretty easy to see the differences in the real world. Take OS X vs. Windows. I don't presume to know anything about how the development of these products really goes (except to say that Microsoft clearly sucks at it if it takes years of missed ship dates), but the end product makes it pretty obvious. Windows is driven by mountains of legacy and compatibility. OS X, on the other hand, starts with, "I want to do this, so what does the UI look like?" For example, say that you want to run a program. Windows makes you navigate a start menu that assumes too much about what you may or may not know. Try to find Excel on a friend's computer, when they try to keep their start menu "organized." Good luck with that. On OS X, I click the Spotlight icon, begin typing Excel, and there's the icon to click. The evolution of categorized portals like Yahoo to the single simple search box on Google demonstrates similar focus.
Don't get me wrong, you can get out of control. People who start building things in Photoshop or Visio are getting way too ahead of themselves. Scribble something on paper, because it's a lot faster and you won't get attached to it as easily. Start to flesh out what it is you're trying to accomplish for the user, and the fastest way to that point. Figuring out the object abstraction and data access then becomes a natural extension of delivering on that well thought out UI.
I'm going through this exercise right now at my day job (which by the way, I can't believe I've been at for a year, but that's another post). It was also the key, freeing moment for me when I started to rebuild my forum app instead of worrying about how to get my old data into it. It's amazing how much better your software can be when you focus on the task first, and the implementation later.
Mark Cuban can be obnoxious, but I'm right behind him on this one:
Why I Don't Wear a Suit and Can't Figure Out Why Anyone Does!
Never owned a suit, never intend to.
I hired a designer to make some rockin'
icons (thanks, Jenna!) for the forthcoming POP Forums v8. It's kind of
weird how taking a break from the hardcore coding to make things pretty
is a very motivating force. It's like the entire thing becomes more
real at that point.
I finally did something a little AJAX-ish
with it too. I say "-ish" because I didn't wire in the
asynchronous-ness to it just yet. (Making up words is fun!) One of my
pet peeves for online forums is all the useless crap that gets mixed in
with the actual discussion. Seriously, I don't care what your avatar
looks like or when you joined. So in this version, I'm hiding it. Click
a name on this page,
for example. It's really the only significant UI design decision I've
made so far, but you can bet I'm going to refine the crap out of it
until it's mostly good. Less is more.
I didn't use the ASP.NET AJAX pieces because I just couldn't get it to do what I wanted, and this process just went much faster. And hey, I'll have a little script library building up too.
I've also decided to make
another performance tweak, and increase/decrease various counts instead
of counting rows all of the time. Yeah, I probably should have been
doing that six or seven years ago when I first started this forum
nonsense. I'll probably go with the good old "freshness date" approach
to make sure it hasn't somehow fallen out of sync now and then.
don't think I'm going to hit the milestone I was hoping to hit by the
end of the month. While that does bother me to some degree, I'm not
going to let it depress me either.
I'm finally using the AJAX stuff in a project of mine, and I have to say that, for the most part, I'm impressed. The ton of stuff you have to drop into web.config is a little annoying, but there are some amazing tools in there.
I'm a little disappointed with the fact that I can't seem to make any of the stuff work right in a repeater. If there is some way to do it, it's not very straightforward. I tried to use the CollapsiblePanelExtender and had no joy. I didn't look at the source (don't have time, either), but I wonder if it's wiring things up with the UniqueID property of the controls.
Problems aside, I like how many problems are solved for you. Good stuff.
YouTube has a lot of fun stuff, and I
won't deny it of that, but I don't understand where this "revolution"
in video content is. There is little on the Web that qualifies as
anything more than wasting time.
There are certainly some big
advertising opportunities, and it's certainly something to consider as
a growing alternative to broadcast TV (which gets more lame by day).
The press started to jump all over it when LonelyGirl15 was outed as an
actress and not a teenage narcissist who liked to video blog. A wired article about these guys makes the sound like revolutionary pioneers in the new art of Internet storytelling. Things got interesting when suddenly "Bree" became angry with her parents about not being allowed to go out with her male friend.
I don't get is why everyone in the press is praising these guys as
being geniuses. I mean come on, if I made a regular video with a
19-year-old hottie actress that was even remotely interesting, I could
attract a crowd too. It doesn't make me the Internet version of
Spielberg. I watched a few episodes, and I'll agree that she's
convincing, very cute and there's some hint of a plot.
where's the real meat? The average 44 minutes of drama on an hour-long
TV show is what I watch religiously because it's an interesting and
longer lasting escape. It's something to do in my free time. I can
watch half of the LonelyGirl15 episodes in no time flat, and then what?
is no doubt in my mind that the Internet makes new forms of
entertainment possible, and I dig that. But the new entertainment still
has to be as interesting and something more than a time waster. Even
the "Behind The Music That Sucks" episodes on Heavy.com (which have been around for at least six years) are more interesting, and that was done as early and somewhat crude Flash.
As it says... can the VS dev Web server be seen by other computers on the network? It would make testing in Safari and other browsers a lot easier. I can't seem to get the right combination of words on Google to find an answer. So far, no joy.
I ported the data from my reasonably large forum on CoasterBuzz over to an early test build of POP Forums v8. First off I was just relieved that the data was easy to move.
The thing is far from feature complete. It's funny how the basic stuff, users, forums, topics and posts, turns out to be like 20% of the overall work in a forum application. It's all the other stuff that takes time. But breaking it down into little simple parts and iterating like crazy makes it so much easier to manage. Sometimes all you're doing is enabling and worrying about deeper implementation later. For example, there is serious logging going on for all things security related, and moderation is totally logged. Right now there's no mechanism for viewing the data, but it's there.
I've learned some interesting things since the last time I hacked at already hacked code three years ago. Starting over has been very freeing. Among the lessons:
- Stop trying to be everything to everyone, all at once. I realized that I was so worried about how people would look at the code, whether or not it met external and often imagined requirements, if it matched current conventions or feature sets, etc.
- Unit test when it makes sense to unit test. I dig test-driven development, but I've reached the firm conclusion that it's a total waste of time for things that aren't likely to get broken directly or indirectly. I know that's blasphemy to the TDD zealots, but come on man, I've gotta ship something!
- SQL 2005 is the shizzle. Actually, I have little use for the CLR functionality in daily use, but when it comes to migrating data, using CLR-based functions and procedures is hands down, rock your socks, easier than using T-SQL. Deploying in a manner other than via Visual Studio is awkward, but again, I don't plan to use it in normal production.
- ASP.NET's event-driven model is so far and away easier to code for than anything else I've encountered because it's so damn extensible. Things like the DataBound event on Repeaters make the presentation of data so easy to do anything. I don't know why ASP.NET books and online articles do such a crappy job of teaching this stuff. I feel like I could write another three chapters to my book to cover this stuff.
- Performance is everything, and it's easier to tweak when you trace. There are times you can do something silly and end up making multiple database or method calls that have a negligible effect on things until they happen in the wild. There's nothing dirty or wrong with putting Trace.Warn() calls in your code to see exactly what's slow in your app.
Writing code is more fun right now than it has been in ages for me. I'm excited about the platform, about the AJAX framework and getting this thing out the door in a few months. More to the point, I'm excited to serve my audiences better than I do today. Happy audiences are worth more, too.