December 20, 2011 § 1 Comment
This is a short, kind of myth buster article on LINQ. For beginners.
If you don’t know LINQ yet.
LINQ is more a syntactic feature in C#, than a programming feature.
All compiled code are similar whether it uses LINQ, or just implements same stuff without LINQ.
The basis of the above statement is that.. after C#/VB.NET compiler compiles the code with LINQ queries and expressions, it is translated into (auto-generated into) normal method calls or object instances as appropriate for the logic… which would have been similar to what you might have written if you didn’t use LINQ.
An Example is.. Writing code that creates an XML string using XML.Linq is same as code that creates an XML string with XML DOM or XMLDocument… because once compiled all XML.Linq code is translated into XMLDocument or DOM based code. When you use XML.Linq, you allow C# compiler to write all the important code, while we syntactically do short and crisp queries, expressions, and methods.
Why is LINQ Good
Because it generates the standard code that many developers write in different ways. It is like dragging some objects on to your dashboard, link them together, and clicking Start, like in futuristic movies .. and the system already starts functioning.
LINQ is like futuristic programming.
Instead of doing the same old code many times or creating our own data adapters, xml adapters etc., we use LINQ which generates our adapters when the code is compiled (not on the fly during runtime, but at IL level itself), and attaches the data types variables should have on the fly.. so that code writers can simply use the ‘var’ type in most places for variables.
LINQ – to – SQL
LINQ to SQL, is a set of interfaces, classes, that allow us to create LINQ queries or expressions on our data sources the easy way.. instead of creating data layers with data adapters and entity objects.
By doing LINQ-to-SQL we allow a C# / VB.NET compiler to generate our data adapters and entity objects for us in the IL level code that is run by the CLR.
Saves us time, planning, building code or libraries or patterns .. which can all now be generated quickly the standard way by the compiler.
Makes it quicker.. so in a few minutes you can query your DB directly, or through its SPs.. without writing one line of data layer code in C#.
LINQ – to – Objects
Allows us to create query-able objects and use them.. load data into them or query data from them.
Why LINQ-to-Objects, We already have collections
But collections are only enumer-able, not query-able. You can’t do a where, select, etc., on collections, like we can in LINQ objects.
Designing objects that powerful is what LINQ-to-objects is all about.. and again without planning, designing and creating them… and just allowing the compiler to auto-generate them, with all the required infrastructure to allow querying.
LINQ – to – XML
Allows us to read, create or modify XML without all the overhead of XML DOM objects and appendchild and selectnodes we used to do.
Is LINQ synonymous with High performance
It is.. if we understand how to use it properly.. so that the compiler can generate high-performing code. If we write complex expressions in such a way that the compiler translates it into many method calls nested within each other and many loops are generated in the resulting translation by the compiler, then it is not high performing.
Just because LINQ is used doesn’t mean code is better performing.
And all that we read about performance on LINQ-to-SQL, or LINQ-to-XML or LINQ-to-Objects is about what would make the compiler generate good, performing code when our LINQ use is compiled…not that LINQ would magically create better performance than normal way of doing the implementations without LINQ.
- Saves a lot of Development time.. so we do only the wiring needed, and the compiler takes care of all the actual standard implementation blocks that it has to be translated into. Time saved is the biggest advantage of LINQ, more than anything else.
- LOC – lines of code decreases considerably.. of course only in medium/bigger implementations.
- Many other core Advantages can be said of LINQ.. but they all wrap up to the above point.. that LINQ writes the blocks for us.. so a LINQ-to-SQL guy would say LINQ generates all the data layer, entities, creates neccessary data type, accepting DB changes is easier, etc., as advantages.. but all the guy means is he is just doing drag-drops or clicks and code is auto-generated and only wiring is needed.
- A beginner level C# or VB.NET developer, who has had little SQL querying experience can quickly code great with LINQ and interacting with data sources, objects and xml… without needing to understand in a big way the tech involved in ADO.NET, XML DOM, OOAD.
- There are already tools and applications which allow non-programmers or business users learn basic querying constructs, write LINQ queries, and see data in reports the way they want. LINQ-pad is basic example.
- LINQ is futuristic programming.
- Beginners who get very used to LINQ, find it hard to improve performance of their LINQ code blocks because they are not strong with tuning the sources that LINQ works with. (and also may be because they don’t understand performance tuning of LINQ expressions for the same reason)
- LOC – Decrease in lines of code may not be big or important on some implementations, where the amount of query-able logic needed is less. i.e., where scope for using LINQ is less.
- Readability of code decreases considerably.. especially in bigger implementations where datasources are big or huge.. and it is further worse if code has many delegates + anonymous methods.. as delegates/anonymous methods are commonly used along with LINQ. Even experienced LINQ programmers will find too many anonymous methods, delegates, and LINQ queries / expressions complex to debug.
- Learning LINQ and using it has an overhead for an experienced developer. Anonymous methods, Func<>, Action<>, predicates, etc., there are so many shortcut programming to learn and proper programming to un-learn.
- Sometimes, programmers who can’t forget their normal programming model for a while when using LINQ.. end up rethinking or reverting their use of LINQ expressions.. especially when the expression or query doesn’t return what they expected.
- If all or most developers in a team don’t know LINQ, and LINQ is attempted to be used, it causes time delays and confusion with working or maintaining the code, rather than saving time.
Most of the above Cons are arguable.. especially because of the strong first point in the Pros.. “shortening & auto-generating standard code saves time”.
At the syntactical level / readability level, though, LINQ vs normal code writing, is almost similar to debate on SMS vs proper text messages.
Use of LINQ for small, one time functions should be avoided.. sometimes it is just syntactic sugar or stylish.
LINQ should rather be used to fully automate implementation for things like parsing or creating XML, working with Databases or even multiple datasources like xml, rss, atom, database tables, and objects.
December 16, 2011 § Leave a comment
And sure enough, ask a random programmer when they do their best work and there’s a high chance they will admit to a lot of late nights. Some earlier, some later. A popular trend is to get up at 4am and get some work done before the day’s craziness begins. Others like going to bed at 4am.
At the gist of all this is avoiding distractions. But you could just lock the door, what’s so special about the night?
I think it boils down to three things: the maker’s schedule, the sleepy brain and bright computer screens.
The maker’s schedule
Paul Graham wrote about the maker’s schedule in 2009 – basically that there are two types of schedules in this world (primarily?). The traditional manager’s schedule where your day is cut up into hours and a ten minute distraction costs you, at most, an hour’s worth of time.
On the other hand you have something PG calls the maker’s schedule – a schedule for those of us who produce stuff. Working on large abstract systems involves fitting the whole thing into your mind – somebody once likened this to constructing a house out of expensive crystal glassand as soon as someone distracts you, it all comes barreling down and shatters into a thousand pieces.
This is why programmers are so annoyed when you distract them.
Because of this huge mental investment, we simply can’t start working until we can expect a couple of hours without being distracted. It’s just not worth constructing the whole model in your head and then having it torn down half an hour later.
In fact, talking to a lot of founders you’ll find out they feel like they simply can’t get any work done during the day. The constant barrage of interruptions, important stuff ™ to tend to and emails to answer simply don’t allow it. So they get most of their “work work” done during the night when everyone else is sleeping.
The sleepy brain
But even programmers should be sleeping at night. We are not some race of super humans. Even programmers feel more alert during the day.
Why then do we perform our most mentally complex work work when the brain wants to sleep and we do simpler tasks when our brain is at its sharpest and brightest?
Because being tired makes us better coders.
Similar to the ballmer peak, being tired can make us focus better simply because when your brain is tired it has to focus! There isn’t enough left-over brainpower to afford losing concentration.
I seem to get the least work done right after drinking too much tea or having a poorly timed energy drink. Makes me hyperactive and one second I’m checking twitter, the next I’m looking at hacker news and I just seem to be buzzing all over the place..
You’d think I’d work better – so much energy, so much infinite overclocked brainpower. But instead I keep tripping over myself because I can’t focus for more than two seconds at a time.
Conversely, when I’m slightly tired, I just plomp my arse down and code. With a slightly tired brain I can code for hours and hours without even thinking about checking twitter or facebook. It’s like the internet stops existing.
I feel like this holds true for most programmers out there. We have too much brainpower for ~80% of the tasks we work on – face it, writing that one juicy algorithm, requires ten times as much code to produce an environment in which it can run. Even if you’re doing the most advanced machine learning (or something) imaginable, a lot of the work is simply cleaning up the data and presenting results in a lovely manner.
And when your brain isn’t working at full capacity it looks for something to do. Being tired makes you dumb enough that the task at hand is enough.
Bright computer screens
This one is pretty simple. Keep staring at a bright source of light in the evening and your sleep cyclegets delayed. You forget to be tired until 3am. Then you wake up at 11am and when the evening rolls around you simply aren’t tired because hey, you’ve only been up since 11am!
Given enough iterations this can essentially drag you into a different timezone. What’s more interesting is that it doesn’t seem to keep rolling, once you get into that equilibrium of going to bed between 3am and 4am you tend to stay there.
Or maybe that’s just the alarm clocks doing their thing because society tells us we’re dirty dirty slobs if we have breakfast at 2pm.
To conclude, programmers work at night because it doesn’t impose a time limit on when you have to stop working, which gives you a more relaxed approach, your brain doesn’t keep looking for distractions and a bright screen keeps you awake.
(Source : A geek with a hat)
December 16, 2011 § Leave a comment
This topic is specific to a legacy technology. XML Web services and XML Web service clients should now be created using Windows Communication Foundation .
This topic describes how to enable tracing in Web services built with ASP.NET in .NET Framework version 3.5. Enable tracing to identify how to increase performance and stability as well as increasing the ability to troubleshoot Web service issues.
Tracing for ASMX
To enable tracing for ASMX, use the following sample configuration.
|Tracing is only enabled when the application is fully trusted.
<system.diagnostics> <trace autoflush="true" /> <sources> <source name="System.Web.Services.Asmx"> <listeners> <add name="AsmxTraceFile" type="System.Diagnostics.TextWriterTraceListener" initializeData="local.log" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, ProcessId, ThreadId" /> </listeners> </source> </sources> <switches> <add name="System.Web.Services.Asmx" value="Verbose" /> </switches> </system.diagnostics>
All traces (except exceptions and serializations errors) use Information level. The exception traces uses Warning level for exceptions that are handled, and Error level for others. If the Trace level is Verbose, the exception stack is also traced, otherwise, only the exception type, the message and the code method where it was caught are traced. For serialization and deserialization errors, if tracing is enabled, serialization events are used to track the unknown elements and attributes in the SOAP message.
On the client side, the trace points are the followings,
- Before and after Request Serialization
- Before and after GetWebResponse
- Before and after Response Deserialization
- Before and after XmlSerializer Creation
On the server side, the trace points are the followings,
- When the IIS Handler is called
- Before and after Request Deserialization
- Before Dispatching
- When the server method returns
- Before and after Serialization of response
- Before and after XmlSerializer Creation
(Source : MSDN)