Here's all the code you need to display your favorite YouTube video on your site:
<object width="425" height="350">
<param name="movie" value="http://www.youtube.com/v/uhYbrORmJ5I"></param>
<embed src="http://www.youtube.com/v/uhYbrORmJ5I" type="application/x-shockwave-flash" width="425" height="350"></embed>
</object>
I can envision this as the next scrolling marquee, dancing baby phenomenon that took over the web back in the day... Bandwith be damned! Did any of you ever see the site that sold advertising space in tiny 10x10 pixel squares? Maybe I'll create the first site to display thousands of tiny little videos, and we'll bet the over/under on how many seizures per hour I can induce?
I spent some time today reviewing test questions for the MCPD Web Developer upgrade test, and I found a few pretty trivial items that may benefit coders new to ASP.NET 2.0. Not earth shattering, but...
Don't forget about the CompareValidator control's TYPE and OPERATOR properties. Type can force input to specific data types: Dates, Currency, Double, Int and String, while Operator enforces Data Type validation, or value comparison expressions (greater than, not equal, etc.).
These validators are often overlooked, but provide a ton of power; when combined together they almost completely handle data input without requiring server round trips. Keep in mind you're still on the hook for verifying what the user gave you, and for protecting against malicious data (SQL injection, etc).
<%@ Page Language="C#" AutoEventWireup="true" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>Date Validation Test Page</title>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:TextBox ID="TextBox1" runat="server"></asp:TextBox><asp:Button ID="btnValidate" runat="server" Text="Validate My Date" />
<asp:CompareValidator ID="CompareValidator1" Display="none" runat="server" ControlToValidate="TextBox1" Type="Date" Operator="DataTypeCheck" ErrorMessage="This is not a date."></asp:CompareValidator>
<div style="margin: 2em;font-size:x-large;color:Red;">
<asp:ValidationSummary ID="ValidationSummary1" runat="server" />
</div>
</div>
</form>
</body>
</html>
Jeff Atwood posted this article on Coding Horror, which details his (and others') views on object oriented programming. A very interesting debate, since most of us were taught that OO is the king of kings... like everything, it looks like too much of a good thing can turn ugly. I call it the Berenstein Bears "Too Much Birthday" maxim:
http://www.codinghorror.com/blog/archives/000087.html
My thoughts? We had a nice discussion today about some legacy code's programming style... on first glance, it looked very complex ("Advanced code", if you will), but once you started digging in, the code started to feel less impressive and more cumbersome... this article couldn't have found me at a better time, as I was wading through huge chambers of abstraction and hard to follow design...
I'm all for utilizing the power of OO, but I think this is an interesting read for anyone starting to really grasp programming techniques.
We just finished up a Windows Communication Framework (WCF) Master Class taught by Juval Lowy, President of IDesign. Juval has been deemed a Software Legend by Micrsoft, and his knowledge of the WCF was impressive. I was interested in WCF before this class, and now I'm itching to start cranking on some WCF projects. I'll be sure to post here once I get something interesting underway.
For now, I've just posted some shorthand notes from our discussion of concurrency management. This obviously insn't a comprehensive list, but shows the main topics regarding concurrency we reviewed.
Service in-memory state
Client in-memory state during callbacks
Shared Resources
Static Variables
PerCall is by definition thread safe instance
Each call gets a dedicated instance
State store is NOT thread safe
PerSession requires concurrency managment
Singleton also must synchronize access
Multiple instances on multiple threads
ConcurrencyMode.Single:
Default value
Auto synch
Disallows concurrent calls
One caller at a time
Callers handled FIFO, placed in queue
Timeout defaults to 1 minute
Keep operations session-ful and singleton services short to avoid blocking for long
ConcurrencyMode.Mutliple:
Allows mutliple calls up to throttled concurrent calls value (default of 64)
Using .NET locks to synch access to its state
Lock just when required
Allow other clients calls in between
Does not queue up messages
This is a tad goofy, though, because sessionful and singleton don’t scale, so why scale throughput but not these?
[ServiceContract(SessionMode = SessionMode.Required)]
interface IMyContract
{
void MyMethod();
}
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple)]
class MyService : IMyContract
{
int[] m_Numbers;
List m_Names;
public void MyMethod()
{
lock(this)
{
...
}
/* Don't access members here */
lock(this)
{
...
}
}
}
BETTER TO LOCK ON (this) to hold entire object body, instead of locking particular members, to enforce safety even if other members are added later… add as static to avoid this, but if developer doesn't think to do this, then partial safety results, and deadlocks are possible as threads lock down resources in different orders.
ConcurrencyMode.Reentrant:
Refinement of .Single
No concurrent calls
Singles can deadlock when call chain references themselves
Reentrant avoids this by allowing reentrance into service instance, avoiding deadlock (Silently releases lock)
Created for duplex callbacks, as callback will reference calling client operation
Thread affinity - The assumption you always use the same thread
UI & TLS (local store) can assume thread affinity, but services cannot
Some cool form update examples in these examples (Application.OpenForms) updating of form controls, etc.