Archives
-
dotnetpro.tv Tipp - Programmiertipps als Video einmal anders
Das neue Videoformat dotnetpro.tv für Entwickler hat Zuwachs bekommen: den dotnetpro.tv Tipp
-
Coole Buchreihe: Wissen kurzweilig vermittelt
Wer .NET TV und dotnetpro.tv (bei der dotnetpro) mag und auf der Suche nach weiteren kurzweiligen Informationsquellen ist, der sollte sich einmal die "Head First"-Buchreihe von O'Reilly anschauen. Da gibt es zwar vor allem Java-Bücher, aber auch ein empfehlenswertes zu Design Patterns für die Freunde von .NET:
-
APress Bücher richtig günstig
Am Wochenende bin ich in der Lehmanns Fachbuchhandlung in Hamburg über ein Regal mit vielen interessanten APress-Titel zu sehr günstigen Preisen gestolpert. Statt 49 EUR so um die 12-14 EUR kosten sie. Eine Liste der Titel findet sich hier:
-
How to Integrate Your Own XML Document Types into VS.NET Projects
I. Enable Intellisense Support
-
Neues Videoformat für Entwickler: dotnetpro.tv
Vor mehr als einem Jahr habe ich dotnet.tv (bzw. .NET TV) begonnen zu produzieren. Inzwischen sind 8 Folgen erschienen und viele begeisterte Zuschauerstimmen haben gezeigt, dass Video ein geeignetes Medium zur Wissensvermittlung ist und darüber hinaus einfach aus Spaß machen kann.
-
Making of dotnet.tv - Folge 8 - Aus dotnet.tv wird .NET TV
Der Sommer geht, dotnet.tv kommt. Nach einer kleinen Sommerpause startet dotnet.tv wieder mit einer brandneuen Folge.
Während Sie in dotnetpro 9/2004 als Trostpflaster für unsere Sommerpause nur einen "best of"-Rückblick auf die ersten 7 Folgen sehen konnten, präsentieren wir jetzt als frisches Thema XML.
Aber nicht nur das Thema ist frisch, sondern auch der Auftritt von dotnet.tv. Wir haben die Zeit genutzt für ein Redesign.
Statt monatlich ein Thema in einer Folge zu behandeln, "senden" wir nun wöchentlich. Und statt einer langen Folge (30-40min) pro Thema, werden es nun vier kurze (5-10min) sein. Eine solche Stückelung schien uns günstig, um Ihre Aufmerksamkeitsspanne weniger zu strapazieren. Denn Entwickler im Projektalltag sind wahrscheinlich eher bereit, öfter mal 10min in die "Fortbildung" zu investieren, als sich 40min aus den Rippen zu schneiden. -
Smooth unit testing with NUnit and VB.NET
Unit testing .NET Fx projects basically is easy with NUnit and I don´t want to add to the literature on unit testing at this point.
-
dotnet.tv in English - A Video Series for .NET Developers - Finally it´s online!
Check out dotnet.tv Episode VI on WebServices [100 kbps streaming video] and let us know what you think.
-
Making of dotnet.tv 7 - Multithreading - Drehtagebuch
Und wieder ist eine dotnet.tv Folge im Kasten! Puh. Thema: Multithreading. Und gab es neue Herausforderungen zu meistern. Diesmal mussten wir wirklich alles innerhalb von 5 Tage drehen und schneiden und komprimieren. Da gab es kein Vertun. Alles musste vom 24.5. bis 28.5. geschafft sein.
-
A Changed View on Application Architecture: Final Remarks on How to Host Businesslogic
In the past days I tried to explain, what I think has to change in our application architecture message for the majority of developers now. My main point is: We need to change how we depict the parts of an application (i.e. frontend, businesslogic and backend). We don´t need to introduce new technologies/concepts, but just shift the implicit/explicit emphasize on existing ones.
-
Full duplex continued: Moving closer together
Knives back in our boots I like Clemens' new post quite bit. Or even: I agree with his solutions for the scenarios depicted.
However, I know few developers who are going to build such kind of systems within the next 10 years. Or to be honest: I know none.
That doesn´t mean, I think there are none, but only makes a statement about the 5000+ developers I "touch" each year.
As useful and necessary Clemens´ solutions are, I don´t think, we can motivate those 5000+ developers to adapt them anytime soon. Plus, I still doubt they make sense for all of them. At least as long as the technology to implement them is not here and easy to use. (Always remember COM+: A good technology and sound concepts below it do not guarantee broad success and adoption of the ideas!)
This is why I still cling to the notion of in-proc resource components. Or maybe I should call them light weight services? ;-)
Anyway, I don´t see Clemens and me that far apart in our views. We´re just looking at applications of different scale. This becomes clear, when I say, that Clemens´ "data services" are treated as separate applications in my architectural picture. Just because some component delivers data, I don´t think it can only be a resource component. If it´s big enough (or independent/autonomous enough) sure it can be made into an application of its own. SQL Server for example is an application of its own - but my application should communicate with it thru a resource component wrapping an abstraction layer around its services. -
Full duplex: How I seem to have tricked Clemens Vasters into mentioning me several times in his blog - but in fact probably just was misunderstood
Well, well, fellow German RD Clemens Vasters obviously found some time to read my blog between his job as a (probably fulltime) "architecture consultant" and writing "more code on a monthly basis than some full-time application developers"; so in his blog entry he honors me with some mentions of my recent "discoveries".
-
A word on why I´m an advocat of more rules
If you´ve been following my thoughts on changing our view of the application architecture (of business apps), then you might have gotten the impression, I´m very firm in my views and want everything to be governed by clear rules not to be broken.
-
Drill down on the communication between application and resources - Bonus: The reporting puzzle solved
Yesterday I drilled down into my new view on application architecture to explain, how I think frontends and application should communicate.
-
Drill down into a view on application architecture: Communication between frontends and application
In my last blog entry I suggested a new view on basic application architecture (at least for "business applications"). The purpose: to change the patterns in which developers think, so concepts like Application Server no longer are deemed esoteric tools for only a few.
-
Suggestion for a changed view of basic application architecture
Web services were yesterday. Today is SOA (Service Oriented Architecture). And what´s tomorrow?
The only constant about buzzwords is change. -
Our view of applications and databases needs to change: Think more services!
After 5 locations of Microsoft DevDays tour throughout Germany and my talk on building a data access layer and several conversations with colleagues and attendees, I´m now convinced of the following:
-
Only one day to go
With only one day to go, I´d say I´m at the door step of an exciting new phase of my professional life.
-
From stoneage to modern software development
Many things have changed since the stoneage. Many!
-
Panta rei - Everything flows
If everything flows, how can I resist the flow?
-
dotnet.tv 6 - Finally the Video Series for .NET Developers Makes its Debut in English
Finally we made it: After 5 installments of the German video series for .NET developers we did the current one in English. The topic WebServices called for a standard language ;-) and we wanted to see, how an international developer audience reacts to our efforts to explain .NET technologies using video.
-
Neue technische Möglichkeiten für dotnet.tv???
Beim Gespräch heute mit dem Sohn einer Bekannten - Maximilian, 15 Jahre - bin ich heute über ganz neue - oder alte? - technische Möglichkeiten für das Filmdrehen gestolpert. Maximilian hatte mit einer Digitalfotokamera Legofiguren fotografiert und zu Fotocomics zusammengestellt (ähnlich wie bei Bravo usw. die Fotogeschichten). Ich war beeindruckt von seiner Kreativität und fühlte mich erinnert an meine süßen Jugendjahre (war ich damals 12, hm...???), in denen ich einige Stop Motion Filme mit einer 8mm Kamera gedreht hatte.
-
ObjectSpaces: Projection or sparse Objects?
My previous blog entry raised some comments I´d like to respond to.
-
Spans in ObjectSpaces are not enough - Proposal for sparse population of persistent objects
Matt Warren has provided a look behind the scenes of how features of ObjectSpaces (OS) come into existence in his blog entry "ObjectSpaces: Spanning the Matrix". The entry plus the comments are an interesting read in that they show, how technology features are dependent on single people who advocate them, and how Microsoft watches the market of competive products and needs of developers. Good to know, in the end it´s all just humans at Microsoft :-)
-
Making of dotnet.tv Folge 5 - Drehtagebuch
Folge 5 von dotnet.tv zum Thema "Code Access Security" ist abgedreht. Und natürlich habe ich wieder in einigen Postings unsere Abenteuer dabei beschrieben. Eine Übersicht der Drehtagebucheinträge findet sich hier:
-
Making of dotnet.tv Folge 5 - Drehtagebuch Tag 7+8
Und immer wieder gibt es etwas neues zu lernen bei dotnet.tv, zum Beispiel, wieviel Aufwand hinter schnell hingeschriebenen Sätzen stehen kann.
-
Making of dotnet.tv Folge 5 - Drehtagebuch Tag 5+6 - Die CLR bekommt ein Gesicht
Zum Teil war es schon vorauszusehen gewesen, dass wir auch am Wochenende würden reinhauen müssen, da Sebastian in dieser Woche für einen Monat in Ausland muss, um mehrere Workshops zu halten. Aber dann hatten wir doch gedacht, wir würden am Wochenende nur gemütlich schneiden.
-
Making of dotnet.tv Folge 5 - Drehtagebuch Tag 3+4
Donnerstag war für Sebastian und mich ein besonderer Tag: Ganz inspiriert vom gewaltigen Oscar-Erfolg von HdR3 haben wir gleich zwei Videos gleichzeitig gedreht! Zum einen standen Szenen für dotnet.tv 5 auf dem Plan, zum anderen mussten wir noch ein Interview mit Thomas Fickert für den ersten Community Clip drehen.
-
Making of dotnet.tv Folge 5 - Drehtagebuch Tag 1+2
Kaum war die Folge 4 von dotnet.tv geschnitten, ging es auch schon an die Planung von Folge 5. Da Sebastian ab 10.3. für einen Monat im Ausland ist, müssen wir den Dreh der Folge 5 schon jetzt durchziehen - mit kaum 14 Tagen Abstand zum letzten.
-
Technical Summit 2004 in Kassel mit Dev LAN Party
Microsoft hat nach langer Zeit mal wieder einen "richtigen Entwickler-Event" gemacht: den Technical Summit in Kassel. Thema waren die Neuerungen, die mit dem .NET Framework 2.0 und VS.NET 2.0 (Codename Whidbey) kommen werden sowie ein Ausblick auf die nächste Windows Version (Codename Longhorn).
-
Embedding ObjectSpaces Mapping Info in an Assembly
ObjectSpaces needs three XML documents to completly define the mapping between persistent classes and SQL Server databases. However, keeping these mapping files separate from the application code has the drawback, that mapping info and code/class definitions can get out of sync. You need to remember to always deploy three additional files with your app's assemblies.
-
Making of dotnet.tv Folge 4 - Drehtagebuch Tag 6
Es ist wieder mal geschafft: Die dotnet.tv Folge 4 ist geschnitten.
-
Thoughts on how to bind to databases, or: Databases as services
There´s much talk about O/R mapping tools lately in the .NET world. ObjectSpaces are slowly materializing and more and more 3rd party vendors are offering their solutions. But when looking at the different solutions I´m still feeling kind of uneasy. But today I have been able to lay my finger at least on part of the reasons for my uneasyness: I´m not yet satisfied with the way we bind our programs to databases.
-
Making of dotnet.tv Folge 4 - Drehtagebuch Tag 5
Der heutige Tag war recht unspektakulär. Wir haben nur geschnitten. Allerdings mal wieder an einem anderen Ort: im Café Puck. Denn das Café Puck ist einer der kostenlosen Münchener Hotspots! Dort in der Öffentlichkeit zu arbeiten, gutes Essen zu genießen und nicht den Kontakt zum Rest der Welt zu verlieren, war schon sehr bequem.
-
Making of dotnet.tv Folge 4 - Drehtagebuch Tag 4
Heute sind wir von unserem bisherigen Vorgehen bei der Produktion etwas abgewichen: obwohl noch nicht alle Szenen gedreht sind, haben wir mit dem Schnitt angefangen.
-
Making of dotnet.tv Folge 4 - Drehtagebuch Tag 3
Manchmal klappen Dinge auch. Das ist schon tröstlich. Nach den Pannen gestern lief heute zur Abwechslung mal eigentlich alles wie geplant.
-
Making of dotnet.tv Folge 4 - Drehtagebuch Tag 2
Heute war der erste offizielle, voll geplante Drehtag für die dotnet.tv Folge 4. Alles sah auf dem Papier so schön aus. Und gestern hatten wir auch brav eine Drehplanbesprechung.
-
Making of dotnet.tv Folge 4 - Drehtagebuch Tag 1
Manchmal muss man einfach spontan sein: Eigentlich schreibe ich noch am Drehbuch für die 4. Folge von dotnet.tv. Aber heute haben wir trotzdem schon gedreht.
-
ObjectSpaces questioned: Should object persistence really be thought of as orthogonal functionality?
I know, by asking the question in the subject line, some will view me as a haeretic or as naive or something else. But still, I cannot shed the feeling, that striving for this orthogonality - as Microsoft ObjectSpaces (OS) does - could be harmful. (For my exculpation let me say: since the early 90s I have been a fan of ODBMS and I very much like the thought of transparent object persistence. So I´m all in for a good O/R technology.)Why do I think so? Because I saw what happened to MTS and then COM+. Many developers did not understand, that designing classes to be run in an application server is different from designing class to be run in a rich client (aka winforms client). Microsoft made it too easy (!) to deploy almost any COM object in an app server application. People could do anything they liked, e.g. keep state, have properties in their app server classes. And that made them unhappy in the end, because performance often was low. But not due to a immature technology, but due to misuse.So I hope you can agree, that deployment in an app server is not completely orthogonal to the design of my classes. I need to forethink what I´m gonna do with my classes.The same is true, I now come to think more and more, for persistence. Let me say, at least in many cases. (Maybe sometimes orthogonality is really ok and even desirable. Applications for scientific labs come to my mind, which are more algorithm oriented that database oriented.)The cases, where I think, orthogonality is not desirable are the typical business applications, the ERP systems etc. Developers know exactly which classes will be filled from a database. They know their persistent objects from the start of the design on. And which objects need to be persisted does not likely change over the lifetime of an application.So, why should it be suggested to them: forget your knowledge? As long as they still need to explicitly persist changes and even register new objects with OS for change tracking, transparent persistence is not reached in imperative code. Why then should transparent persistence in deklarative code (type definitions) be so important?Because there already exist classes, whose objects all of a sudden need to be stored using OS? I doubt it. The amount of work to be done in code is still huge.Because it is so much easier to not think about persistence when designing a class and leave it to some other guy to come up with a mapping? I doubt it. It puts much burden on the persistence engine. And it keeps the gulf between OO world and relation world wide open, because it suggests: don´t talk to each other. You database guy, do whatever you want. And you OO guy, do whatever you want. My experience is, this leads to poor performance in the end, when trying to bridge the gap.Or because class design should not be tied to a certain persistence technology, be it OS or some other tool? Well, I guess, that´s the real driving force behind the orthogonality idea.But my feeling is, keeping class design absolutely clean and just spread mapping info across several resources, is the wrong solution.My suggestion would be instead: Give developers a "domain specific language" (DSL) for the definition of persistent classes. No, don´t try to do it in C#/VB.NET with attributes! Because then you would not be free to maybe sometimes derive from a PersistentObject base class. Instead persistent class should be defined in a special language hiding all implementation details from the developer.Like HTML is used as a special language compiled to IL in ASP.NET. HTML is a DSL for the realm of presentation layer programming. And we´re all pretty happy with that. So why not have a special language for data persistence programming?I also suggest, this DSL should not be a fully fledged programming language. No imperative code should be able to be written with it. Whatever business logic needs to be added to persistent classes (to make them less anemic ;-), can be added by derivation or aggregation later on.My conclusion: A DSL would not interfere with how objects are persisted in code. A DSL still would keep the definition of persistent types clean of any persistence tool specifica. A DSL would make it clear to a developer, he´s dealing with a persistent class. A DSL would help close the gap between OO world and relational world.From my experience what went wrong with the MTS/COM+ message, I´d love to see it done better for solutions to the object persistence problem. -
Three ADO.NET ObjectSpaces Newbie Problems Solved
When I started playing with Whidbey´s ADO.NET ObjectSpaces object persistence technology (see [1] for an introductory article) I immediately ran into two nasty problems costing me a long time to solve:
-
Making of dotnet.tv Folge 3 - Drehtagebuch Tag 6+7
Mit einem Tag Verzögerung ein kurzes Resumee der Produktion von dotnet.tv Folge 3:
-
Plan for VB3 to VB.NET/IL Converter
After a couple of meetings with clients still employing VB3 programms, I come to the conclusion, there is need for a "VB3 to .NET" migration tool. There´s still a lot (!) VB3 software running out there - and developers see no way to move it anywhere. Jumping onto the VB6 bandwaggon is not really the thing to do anymore - and an alternative is not in sight.
-
Making of dotnet.tv Folge 3 - Drehtagebuch Tag 5
Die äußerlich aufregenden Tage des Drehens sind vorbei. Heute haben wir mit dem Schneiden von dotnet.tv Folge 3 begonnen. Weniger Aufregung bedeutet das jedoch nicht. Fast im Gegenteil! Denn jetzt stoßen wir wieder in für uns unbekanntes Gebiet vor.
-
Making of dotnet.tv Folge 3 - Drehtagebuch Tag 4
Manchmal geht auch etwas schief. Heute zum Beispiel: nur noch magere 9 Szenen standen auf dem Zettel. Und alle sollten an einer Location gedreht werden, nämlich am Bildschirm.
-
Making of dotnet.tv Folge 3 - Drehtagebuch Tag 3
Auch ein Filmteam braucht mal ein wenig Ruhe. So hatten wir uns für heute nur 9 kleinere Szenen zum Drehen ausgesucht. Nach zweimal 2 Stunden an unterschiedlichen Drehorten war alles im Kasten.
-
Making of dotnet.tv Folge 3 - Drehtagebuch Tag 2
Geschafft. Der zweite Drehtag mit wieder 12 Stunden Arbeitszeit liegt hinter uns. Dass wir das Pensum in der Zeit wirklich hinter uns bringen können würden, hätte ich gestern eigentlich nicht gedacht. Es waren noch Szenen von gestern übrig, die wir nicht hatten drehen können, weil in der Lobby des Hilton immer wieder zuviel los war. Zusammen mit den für heute geplanten Szenen ergaben sich eine Zahl von 36 Einstellungen mit z.T. mehreren Abschnitten - gegenüber 28 am ersten Drehtag.
-
Making of dotnet.tv Folge 3 - Drehtagebuch Tag 1
Es ist wieder soweit: Die Dreharbeiten zur nächsten Folge von dotnet.tv haben begonnen. Und ich bin sehr erleichtert: sie gestalten sich in mancherlei Hinsicht leichter als gedacht. Aber der Reihe nach:
-
Enum login time of users on Windows machine to check for logged on user
In my previous posting ("Check for logged on user on Windows machine") I showed a WMI-based method to check, if a certain user was logged on. Andreas Häber then suggested in a comment, to use the Win32 API function NetUserEnum instead. Since WMI always sounds to me like a heavyweight technology, I liked the idea to resort to "simple" Win32 API calls to solve the problem. Below you find the result of my attempt wrapped in a VB.NET module.
-
Check for logged on user on Windows machine
Motivated by a posting in a user group I tried to find the answer to the question: How can a Windows Service find out, if a user has already logged onto the machine it is running on?