A while back, I wrote an article on
codeproject.com about being able to encrypt the value of an HttpCookie. Adam Tibi wrote a
follow up article regarding this, but the original code still works great as written.
Enjoy!
Just released a new version of my gmaps-api-net (Google Maps Web Services API) for c# due to some bugs in the building of urls in the previous version, v0.10.0. Go snag it from
http://nuget.org/packages/gmaps-api-net/.
The next release, v0.11.0 will have some pretty big changes in the c# api due to some restructuring that I feel is necessary:
- JSON serialization classes are directly exposed as the domain objects, will be abstracting them into a separate namespace and present better controlled domain objects. This will make creating actual domain objects easier that can adjust to situations easier without mucking up the JSON deserialization
- XML de/serialization, not currently available but will be in the future.
In addition, a big feature addition for v0.11.0 will be:
- Signing for Enterprise customers that have a Client ID and Private key generated by Google, giving the business customers many more requests. See
Google Maps API for Business FAQ written up by Google.
In the future, I'm planning on trying to abstract out even the mapping technology in use:
- Use Google Maps, or Bing, or MapQuest, etc via providers on a Common mapping provider framework.
As you may know, every Windows installation starting with Vista has a winsxs directory that takes up a lot of space... not a problem when you have a 500GB volume... but a big problem when you have a VPS with only 40GB of space and the winsxs is taking up 12GB!
Just ran across a post on
HelpDeskGeek.com that finally actually works for reducing the winsxs directory.
dism /online /cleanup-image /spsuperseded /hidesp
I can verify that this command works Windows Server 2008R2 and Windows 7. I don't have a Windows 8 installation yet.
When I ran this command on my Windows VPS, the server's winsxs directory reduced from 12GB to about 8.5GB now...
Whew... space feels good!
I have a pet peeve: designers that always start with reset.css stylesheet.
There are so many flaws with this approach:
- all styles... all elements, everything, is reset to padding 0, margin 0, font-size: 100% (whatever that means) and so forth. So utilizing an h1 requires "restyling" an h1 to be somewhat bigger, somewhat bolder than the average text. And make that bigger and bolder than h2, and likewise h3, and likewise h4, h5, and h6.
- the css inheritance chain is difficult to navigate. Since the reset.css touches every single element, and after you've spent time "restyling" every element to have their semantic meaning reflect their visual cues, you end up with many overrides to every style. IMO this makes it more difficult to hone in on what style is not correct.
The advantages of a reset.css:
- every element is consistently lame, lacking the visual cue of the semantics of the text
ENTER THE SAVIOR, Normalize.css...
- It normalizes all elements to reasonable settings. For example, I've personally noticed that the <abbr> element is displayed differently in Chrome, IE, and Firefox. Normalize.css effectively makes the <abbr> tag consistent across all the browsers... winning!
- It tackles bigger problems that were out-of-scope for reset.css, like old browser handling of styles
I would suggest all developers, designers, and HTML gurus to rethink using that reset.css, and look into
getting normalize.css and
put down that reset.css, reset.css is for losers.
Time to rejuvenate the blog. Many things afoot in the world of developement.
Of note,
- MVC 4 RC is coming out soon. Eh, I don't really see much new there. A couple of interesting additions but like I said... eh.
- Umbraco 5 RC2 was released. You can get it at http://umbraco.codeplex.com/. Umbraco is a very nice CMS that runs on top of ASP.Net, and version 5 has been signifigantly rewritten to run on the MVC framework. The existing Umbraco 4.7.1 is still a respectable CMS, and there's lots of community-built plugins.
Any body using NHibernate? So far I like it, but it honestly doesn't feel stable. When running tests, sometimes (sometimes!) the queries that ran fine just before bomb out with
Message: expected in: <end-of-text>
The query executed was "from prf_ProfileSection"... not much else to screw up here, yet the parser fails. Then, I recompile the DLLs and run and it works again...
Anyhow, the main question for this blog post is what's your favorite OR/M and how flexible and stable is it?
So now I'm faced with a change that I realize can't be applied... but I really don't want to restart! Reasons are that to get to this point, I had to step through a lot of code line by line, and I needed to make one slight adjustment... and I want to save that adjustment, but continue debugging.
I'm surprised many others haven't been annoyed by this...
Register your view on this feedback item:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=110163
Counting the days (til when??) that I will be able to get my hands on the new Beta 2 bits of VS Orcas.
I look forward to actually being able to use LINQ, the split view for ASP.Net designing, and a few other things... Initializers, lambda's, etc.
...Are spitting out invalid markup... For instance, nhibernate's schema has moved to a version 2.2. whereas CodeSmith's NHibernate templates are still spitting out 2.0...
Anybody worked with them?
After reading this post about LINQ, I think a few people are missing the point of LINQ... LINQ *replaces* any "Data Access layers" that have been created.
When you build methods in your data access layer, like "GetCustomersByCity," you're actually creating a wierd separation between the data and business layers. In a sense, you're defining business logic in your data layer. The important thing to remember, is that your business layer RELIES on the data layer to retrieve and persist entities so the business layer can process them.
LINQ's future
I see the future where LINQ augments our current Data Access layers and eventually most of the hand written code (call into very specificly created stored procedures for data optimization) will become obsolete.
Moving forward, a project would simply use SqlMetal (or any other code-gen engine for that matter) and build the Linq-supporting types into your current Data Access layer. Then, when you add new business logic components, and upgrade existing business logic code, add the newer LINQ-style access into the business layer.
Eventually, you'll find that most of the data access handling will be through the LINQ-execution engine, and less and less custom developed code.
Performance
Of course, there's always a case where a specific method is written to short-circuit some code path for maximum speed... Those particular instances may be better, but frankly, to quote ScottGu's post on LINQ: "LINQ is fast... very fast"
Some other articles about performance with LINQ:
- blogs.msdn.com/mattwar/archive/2007/07/05/linq-to-sql-rico-drops-the-other-shoe.aspx
More to come...
ScottGu has been busy writing some articles about some of the new features contained in the new Beta 2 bits of Visual Studio "Orcas":
- Part 1: Introduction to LINQ to SQL
- Part 2: Defining our Data Model Classes
- Part 3: Querying our Database
- Part 4: Updating our Database
- Part 5: Binding UI using the ASP:LinqDataSource control
So far, its an interesting read... In particular I like the idea of the <asp:LinqDataSource> control, but I'm not so sure the implementation was correct...
At first glance, having a "TableName" property for the control seems counter-intuitive to LINQ, since I question how many times would I only use 1 table...?
However, I'd like to reserve judgement until we get our hands on it and can check out the LinqDataSource control for ourselves.
In the mean time, we all have a lot of cool stuff to look forward to!
When using BoundFIelds and domain objects... BoundFields use some algo that can't traverse the object hierarchy.
What am I talking about? Take for instance a Northwind database, with certain objects mapped to data tables:
public class Customer
{
public int CustomerId;
public IList<Order> Orders;
}
When binding to a list of Orders in a gridview:
int customerId = int.Parse(selCustomer.SelectedValue);
IList<Customer> customersList = CustomerService.GetCustomersWithOrders();
this.GridView1.DataSource = customersList;
this.GridView1.DataBind();
<asp:GridView runat=server id=GridView1>
<Columns>
<asp:BoundField DataField=CustomerId />
<asp:BoundField DataField=Orders.Count /> <!-- CAN'T WORK -->
<asp:TemplateField><ItemTemplate><%# Eval("Orders.Count") %></ItemTemplate></asp:TemplateField> <!-- DOES WORK -->
</Columns>
</GridView>
I keep posing the question to ASP.Net Program Manager ScottGu, but can't seem to get a response. A feedback item was created to address this, yet it seems very low on the priority list.
In all my experience, I cannot understand why such an important feature, needed by anybody using an actual domain model with objects, cannot use BoundFields out-of-the-box. A "workaround" is to use the TemplateField and Eval... but thats just a poor hack. You don't get any SortExpression support. Before ASP.Net AJAX Extensions, you couldn't even use the ClientSide callback framework with GridViews that contain TemplateFields. You'd get an error saying TemplateFields weren't supported... pfft!
This is really disappointing... I'm using NHibernate to do the OR/Mapping and when I pull these fully hydrated objects from NHibernate queries, I still have to find a way to "flatten" the objects before they hit GridViews. LINQ has this ability, but I'm not cleared to use LINQ on this current project.
I say we need to step up the level of discontent with certain features... If enough people complain and validate the problem (via the feedback item) hopefully it'll get fixed in the next 10 years.
In the interim, has anybody recoded BoundFields (perhaps using Mono source code as a template?) to properly evaluate nested Properties on objects?
Has anybody found a decent solution around this problem?
UPDATE: I'm creating a feedback item to re-address this. Link will be here.