Tuesday, January 17, 2012
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.
Monday, August 20, 2007
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?
Monday, July 30, 2007
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
Wednesday, July 25, 2007
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?
Wednesday, July 18, 2007
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!
Thursday, March 01, 2007
An update to the post about BoundFields not able to bind to nested properties.
Hero ScottGu answered back and brought one of the developers into the question. So at least now we've got a ear that can filter through the feedback parsing your words (not to mention that its difficult to use the feedback site... I typically get frustrated with it, and don't even bother to leave a comment)
Hopefully I can steer the ASP.Net team into fixing this (ironically probably easy to fix) and yet so basic.
...On another note, I'm rapidly (or as fast as my cable modem can download) pulling down the new VS Orcas Mar 2007 ctp release... supposedly this is the one WITH the new LINQ bits... can't wait
Wednesday, February 28, 2007
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.
Wednesday, January 17, 2007
Just to impart some experience, by default the Virtual Server 2005 installation makes a link available for you to administer Virtual Server on the "Installation Summary".
Well smarty-pants me decided to use http://localhost instead of http://[machine-name] to try to log in to the virtual server console.
For whatever reason, http://localhost/VirtualServer/VSWebApp.exe?view=1 doesn't work but replacing localhost with the loopback address [127.0.0.1] seems to make it work...
http://127.0.0.1/VirtualServer/VSWebApp.exe?view=1
Now to test out this new VS Orcas!
http://www.microsoft.com/downloads/details.aspx?FamilyID=1FF0B35D-0C4A-40B4-915A-5331E11C39E6&displaylang=en
Ok, so it says "January 2007 Ctp" yet the files are Dec2006 ctp? And installing reveals... no linq! What am I missing here? I'm drooling to try this out! Somebody clue me in... I figure its some big pre-April fools' joke...
Am I really the only one seeing this?
Thursday, August 10, 2006
http://www.shelleytherepublican.com/2006/07/03/americans-demand-justice-tougher-sentencing-for-hackers.aspx
An article full of disinformation and just downright ignorance on a subject that this blogger has obsolutely no clue about. A co-worker of mine clued me in with the following quotes:
I especially liked these parts:
"Fact File: The most skilled hackers call themselves “Script Kiddies” because they use Linux PHP scripts to do all their hacking. PHP is an obsolete programming language that was based on an ammateur implementation of Microsoft’s ASP”
And
“Possessing hacking tools should be a criminal offense: This should include any software designed to circumvent other computer’s security, plus products with known relations to hacking tools. For example the Linux operating system includes DVDRIP (for pirating DVDs), SSH (for breaking into remote computers), and Telnet (an older remote hacking tool). All of these evil programs should be outlawed.”
These are the kinds of people lobbying our government. I think they should join forces with Ted Stevens.
Tubes damn it!
I'm pretty sure this is a joke, but it trully is scarey that these are the kinds of people that at least place themselves within listening distance to our Senators and Representatives up in Congress...
Oh yeah, warning, there's a mildly disgusting picture of a hacker towards the bottom of the article... maybe turn off image downloading before you look ;-)
Tuesday, August 08, 2006
I'm posing a question to the community about which one is better, adding lots of keys into the Page.Cache all with the same CacheDependency set to the same file, OR would you think it's better to cache one dictionary or list structure with the single instance of the CacheDependency?
// set lots of keys with same cachedependency file...
Page.Cache.Add(”key1”, key1object, new CacheDependency(”theFile.txt”));
Page.Cache.Add(”key2”, key2object, new CacheDependency(”theFile.txt”));
Page.Cache.Add(”key3”, key3object, new CacheDependency(”theFile.txt”));
Page.Cache.Add(”key4”, key4object, new CacheDependency(”theFile.txt”));
or another way:
// set one single page.cache value with a single cachedependency...
IDictionary myDictionary = new Dictionary();
myDictionary.Add(”myDictionary.key1”, key1object);
myDictionary.Add(”myDictionary.key2”, key2object);
myDictionary.Add(”myDictionary.key3”, key3object);
myDictionary.Add(”myDictionary.key4”, key4object);
Page.Cache.Add(”MyDictionary”,myDictionary,new CacheDependency(”theFile.txt”));
Of course, getting a value from the IDictionary instance is a little more difficult:
IDictionary myDictionary = (IDictionary) Page.Cache[”MyDictionary”];
if(myDictionary==null) ReinitMyDictionary();
object someValue = myDictionary[”key1”];
versus just pulling directly from Page.Cache... (and remember that we still would have to cast to the specific object)
object someValue = (object) Page.Cache[”myDictionary.key1”];
if(someValue==null) { //either it wasn't found, or was removed... here's the big difference between the two implementations
ReinitMyDictionary();
It seems to be a little cleaner to put the IDictionary instance into Page.Cache, then you know for sure if you have to reload the collection, versus the direct Page.Cache method might be a little more efficient but is somewhat less precise as to what to do when you get a null... Obviously you could do an onRemovedCallback handler to ReinitMyDictionary() and somewhat guarantee for the second way that that key just plain wasn't in the list of keys loaded from, say theFile.txt...
The goal of the algorithm is simply to load theFile.txt's key/value pairs, and if the key isnt found, its just ignored.
I'd like your feedback to see what others would do for this... and what the performance implications are... (multiple casts, versus a single one, etc)