AJ's blog

January 31, 2007

Shiny new web (german)

Filed under: Miscellaneous, SDX, Software Developers — ajdotnet @ 8:08 pm

This is some news for our german readers…

<language culture=de-DE />

:idea: Der Web-Auftritt von SDX ist komplett überarbeitet, runderneuert und neu gestaltet worden.

Für den Auftritt wurde diesmal eine Marketingagentur mit eingespannt (unsere Kunden kommen zu uns wenn sie professionelle Hilfe brauchen ;) – warum sollten wir das anders halten?).
Die Agentur hat dann allerdings erstmal dafür gesorgt, daß wir alle den Kopf hinhalten müssen… 8O . (Die Erfahrung war’s wert, aber ein Jobwechsel kommt nicht in Betracht.)

Viele Stunden und einige Abende gingen dann noch für’s Texten drauf — kein SDX’ler der nicht seinen Anteil daran hätte — und é voilà, das neue www.sdx-ag.de.

Und Schuld an allem ist diese Dame! (Ehre wem Ehre gebührt! ;) )

:arrow: http://www.sdx-ag.de/jobs.aspx

</language>

That’s all for now folks,
AJ@SDX

January 26, 2007

ViewState State …

Filed under: .NET, .NET Framework, ASP.NET, C#, Software Development — ajdotnet @ 10:23 pm

View state is one of those areas the one can use without actually understanding it. But dealing with view state correctly is mandatory when designing a custom control. “Design” in this case begins only after understanding view state technically and includes dealing with various view state implications, leveraging view state for advanced tasks, or gracefully falling back if view state is switched of.
However, trying to find a complete and sufficient coverage of view state turns out to be …, well. Anyway, those hints might help:

The starting point in MSDN for view state is probably “ASP.NET View State“. The better introduction may be “Understanding ASP.NET View State“, but it only covers ASP.NET 1.1.
You may also want to have a look at  “TRULY Understanding ViewState“. Despite falling short of its own claims (to give a complete coverage of the topic, yet view state persistence is omitted and security issues are missing), it’s written quite amusing and also explains some misuse scenarios.

To get a better feeling for the problem side (ever had a grid with a dataset containing 16000 rows in viewstate?), this link might provide some insight: “Death By ViewState” (“I get enough issues relating to bad perf caused by large viewstate that I felt like it is time to dedicate some blog space to it, so here is a typical problem description for this type of problem.”)

The article “Speed Up Your Site with the Improved View State in ASP.NET 2.0” talks about improvements in ASP.NET 2.0, yet it forgot to mention “ASP.NET 2.0 Page State Persister“. Persisters provide a way to manage view state persistence (aptly named, aren’t they?), e.g. in the session instead of on the wire (which causes other problems… — but this might become another post :twisted:).

And by the way, there is a new thing in ASP.NET 2.0, called control state. Which is much like view state (technically identical), but there actually is a difference. See “Control State vs. View State Example” to get a better idea.

That’s all for now folks,
AJ.NET

January 20, 2007

Coding conventions (addendum)

Filed under: .NET, .NET Framework, C#, Software Developers, Software Development — ajdotnet @ 6:50 pm

After thinking about my last post about that topic, I thought some additional information for people wondering about where to start with coding conventions might be prudent:

  1. ANY coding convention will be better than NO coding convention.
  2. If you have no convention in place, MSDN provides a good starting point: “NET Framework General Reference — Design Guidelines for Class Library Developers“.
  3. An alternative or extension may be the following download.

If you followed conventions implied in existing classes and code but have never read a formalized document, I recommend doing it. You may find same clarification (as the people at Microsoft did no allways follow their own conventions), so reading MSDN might be enlighting.
People who change projects or customers regularly should ask for the coding conventions when beginning to work in a new project. This will save you from later trouble. And in case there is none, that might tell you something about the state of the project.

At SDX we built our set of conventions upon the MSDN guidenlines (apart from saving effort, this avoids unnecessary discussions) and added conventions regarding file and directory structures, commenting, and other things. We complemented this with similar conventions for XML, guidelines regarding project setup (tool set, source code control, automated testing, …), and delivery templates (project document, installation document, …).
One major intention we had in mind was: All this is meant to guide and assist the developers, to help them doing their day-to-day work. We did not want to create a bureaucracy that gets in the way of the developer and creates additional burden.

A little bit beyond simple coding conventions, yet a usefull addition is “Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries“.
Another book that covers coding style and quite a few other topics (and is one of my all-time-favourites — I own the first edition published ’93): “Code Complete“, Steve McConnell.

And finally assaf‘s comment on another post deserves to be repeated: http://thedailywtf.com/Articles/Little_Black_Book.aspx ;-)

That’s all for now folks,
AJ.NET

January 14, 2007

Early 2000 and today…

Filed under: Miscellaneous, Software Developers, Software Development — ajdotnet @ 6:29 pm

Last week I did a little talk (about half a day) about XML. Nothing fancy, just trying to raise the level of basic knowledge for some people. I based this talk on a workshop I did early 2000. Which reminded me of the situation we had back then and how it evolved until today…

Early 2000 was in the middle of the XML hype, XML was the silver bullet.
Today we don’t even mention XML anymore, we just use it.

Early 2000 we had the core XML standard, yet the other family members were still in their infancy, which usually led to the usage of precursory — read inconsistent and proprietary — technologies.
Today we have what I call the XML family, namely XML, XML namespaces, XSD, XPath, and XSLT, and everybody has agreed on those.

Early 2000 we built a prototype application that had a server part serving XML (read Web Service), used heavy scripting in IE, exchanged XML data asynchonously with the server, and provided rich editing capability known the only in rich client applications. Then we abandoned it. Proprietary technology.
Today the dead horse (read AJAX) is riding again and even triggered a new hype. And it’s probably here to stay.

Early 2000 we had another hype called WAP — which burned out and died. But in this context we also speculated about push technologies as replacement for SMS.
Today we have blackberry.

Early 2000 we were in the the middle of the “Battle for the Middle Tier“, seeing the two major camps — Microsoft with COM based (read whatever you like) MTS/COM+ against EJB — fighting for the application server market, Microsoft on the loosing side.
Today Microsoft has caught up with .NET, the java community has rediscovered light-weight approaches, and heterogenous environments where both camps work nicely together are far from unusual.

Early 2000 we had a little hype about SOAP and an early notion of WebServices. Mainly it was a protocol intended by Micrososft to gain access to the java world, supported by IBM to gain access to the Microsoft world… . This hype would have died, had it not had such prominent supporters that kept it alive until additional technologies had been set up to constitute the next hype: SOA.
Today we have SOA, used to cultivate heterogenity on the technical level, but more importantly to reshape whole companies on the business level.

Early 2000 I thought I allready know a lot about technology.
Today I know how much I did not know then. Which makes me wonder about the years to come.

What else did I learn from these observations?

  1. Hypes come and go. They are important, they take us somewhere, surprisingly mostly forward. Unfortunately you never know where “forward” actually is until you are there.
  2. Fighting over technologies isn’t worth the effort. Any technology with serious support is likely to stay, technologies without will die. This is only loosely related to the quality particular technologies.

Sorry if I got a little nostalgic, maybe due to the change of the year and my approaching birthday… ;-)

That’s all for now folks,
AJ.NET

January 6, 2007

Coding conventions are a precondition to readability

Filed under: Software Developers, Software Development — ajdotnet @ 10:57 pm

The other day I talked to a collegue about some technical details and doing this I took notes directly in code. When we finished this collegue asked me not to delete these comments. A little peculiar in itself (who would have done such a thing?) in this particular case the comment had a double meaning: The code being some more or less complex mapping of numeric ranges would not have been comprehensible without comments. And in my opinion incomprehensible code is worse than bad code. Bad code can be fixed after all.

About the same time I stumbled over an article that pointed to “Proof reading is more important than composition“. The authors opinion about readability is something to applaud. All the more irritating how wrong his conclusions are (just my opinion of course!). He deprecates coding conventions as being of adverse effect for readability. Having worked on software in teams of up to 80 developers and of different age (in terms of versions and maintenance impact) I am accustomed to read and evolve existing code as well as write code that has to be understood by other developers after I have moved on. And of one thing I am certain: Coding conventions are a necessary requirement for readability. Of course they are not sufficient, but do away with them and readability will follow shortly. All it needs is the next developer working on the code and using his personal coding style. This has to happen only once, no way to put the chicken back in the egg.

While the author of this article started with a right assumption and quickly got it wrong, the author of the article that pointed to it did the opposite: He started with a wrong assumption (“few people actually … are going to come back and read that code” — if the code matters, people will come back) but he quickly gets it right. I especially like his distinction between programmers and developers:

  • Programmers write code to solve problems
  • Developers write code that can be read by other people and to solve problems

I recommend reading that post because the author makes some good points getting there and even better ones based on that statement.

That’s all for now folks,
AJ.NET

The Shocking Blue Green Theme Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 244 other followers