Panagiotis Kanavos' Weblog

The end of an era - Dr Dobb's last issue

I just received the last issue of Dr Dobbs Journal. Effective in January 2009, Dr Dobbs will stop as an independent magazine. Instead, a Dr Dobbs report will be added to the Information Week magazine. This is the last of the great IT magazines to close. Magazines like the Journal of Object Oriented Programming, the C/C++ Users Journal, the Windows Developer Magazine and Software Development magazine. One by one those great magazines either closed or merged - into Dr Dobbs itself. It was a sad process to see those magazines diminish - literally get thinner and include more and more ads as they tried to reduce costs and improve revenues. Unfortunatelly, the reduction in content drove readers away and one by one the magazines closed. At merely 48 pages, the last issue of Dr Dobbs is painfully thin compared to the 100 pages of previous years.

I trully believe that I've learned more from those magazines than any book or course I ever took. They both taught and broadened my horizons. It is really sad that people prefer blogs and sites instead of magazines. The quality of the articles of the magazines was vastly superior to the quality of most blogs. With columnists like Scott Ambler, Martin Fowler, Herb Sutter, Grady Booch and many others, in-depth articles on subjects raining from driver developoment to patterns and from CMM to agile development, those magazines provided both breadth and depth of coverage. Their Book Review columns were invaluable for separating good from bad books and selecting the best - a far cry from other magazines' "summary of the publisher's summary" reviews. I first read about patterns in those magazines, I heard about the GoF book and several others by Fowler, Martin, Booch and Jacobson on their reviews. Those magazines showed me what the state of the art in IT was.

At least, the last of the great magazines can't close. IEEE Software is published by the IEEE Computer Society so it will stay in print as long as the Computer Society exists (I hope).

Accelerating Infopath Forms in Sharepoint 2007

A friend recently encountered a performance problem using Infopath forms published through Sharepoint 2007 Forms Services. One of his clients used Infopath forms for data entry and experienced delays of several seconds when moving from one field to the other. In a data entry scenario this translates to a lot of wasted time. The strange thing is, performance under Firefox was a lot better!

Luckily, Tim Pash discusses this very thing in Tips and Tricks for Tuning Forms Services Performance. The important thing to note is that Sharepoint and Infopath forms make heavy use of Javascript and postbacks. The trick to improving performance is to improve the execution speed of the Javascript code and reduce the processing time for each postback. Here are some tricks from Tim Pash, and Microsoft's Improving the Performance of Infopath 2007 Forms whitepaper, with some personal notes as well.

• Use the latest version of IE available. IE 7 can execute Javascript code about 5 to 10 times faster. IE 8 feels like it is 10 faster at least. It can also download more than two javascript files at a time, further reducing a page's load time. Pages that would render in several seconds in IE7, render in less than half a second in IE8.
• Install Sharepoint 2007 SP1. It includes performance improvements in the javascript files - and fixes some annoying errors too.
• Don't try to integrate data from many different systems in the form itself. Each query costs time, and has to be repeated after every postback.
• Populate dropdowns from an XML file that is part of the form's XSN. This can be cached and avoids the extra query after each postback.
• Conditional rendering can be slow too. You can replace it by creating multiple views per form.
• Rich Text boxes are slow too. These are only supported under IE, so that may account for the improved performance under Firefox - they aren't executed there!
• Fine-tune the round tripping behaviour of controls using the Browser Forms tab. The less round trips the better. And, as Tim Pash suggests, have them triggered by buttons, so the users know what caused the delay.
• This one is mine. Instead of putting complex logic in the form, put it on the server. You can create an event receiver using C# or VB.NET and register it on the form's library. This way the code is executed in managed code only when the form is actually submitted.

ARCast.TV - Extensible ERP with SingularLogic

Does anyone remember an old blog post about "The Architecture that Wasn't!", where I promised to write about an architecture that allows the creation of complex applications so easily that anyone who hasn't used it, doesn't believe it is possible? Even though this architecture has been succesful for over a decade? And then I forgot to write about it?
It seems that SingularLogic, arguably the largest software company in Greece has become a believer.

In his last Arcast, Ron Jacobs interviews Elias Theocharis of SingularLogic, who describes the new ERP platform they are building based on .NET, WCF and Workflow Foundation. The platform seems to be model- and workflow-driven, allowing implementers to easily create or customize business processes using workflows. Instead of providing its own customization/development environment, the platform integrates with Visual Studio using Guidance packages. This provides a familiar and powerful environment to developers and implementers although it makes it harder for consultants or customers to customize the application. Currently, SingularLogic is creating application components. Although it is not mentioned, I expect the components will contain the models and workflow definition for specific application domains.

During the interview, Theocharis mentions his concerns about WF's scalability (16:21). An ERP platform has to scale from a few concurrent users to several hundrend or even thousands of users. Well, Dimitris Panagiotakis and I can guarantee that workflow can scale - if you take care. Dimitris and I worked at K-NET Group in 2002 building just such a model driven platform. Dimitris built our workflow engine, I did the COM+ and database stuff. Our main customer was the Central Depository of Athens who wanted to automate its back-office processes. The system had to support 200 concurrent business transactions, so we had to make sure there were no bottlenecks. Well, we did OK as the system achieved 10,000 concurrent business transactions during test runs - right before the switch connecting the test clients and the servers started droping packets!

What we did was follow the scalability mantras as much as possible. Our platform stored the definition of domain objects in a configuration database and generated the stored procedures and view that mapped the objects to the application database. Apart from standard actions like Create, Edit, Delete, Print, Show Report, the developer could create new object actions using VBScript, which was also stored in the object's definition.

Here are some of the things we did to ensure the system was as scalable as possible

• No direct modifications to the objects or the database were allowed. Everything had to be an action. This way a client only had to send the following data to the COM+ components: ObjectID, ActionID, action parameters. The processing component would then load the object and perform the action. Objects were kept in memory only as long as they had to.
• We limited the use of used shared resources (e.g. memory, connections) as much as possible.

  • We used object pooling on our Data Layer component to limit the number of concurrent database connections (there was no way to put a limit to connection pooling back then). Although this may seem counterintuitive, fewer connections means fewer blocks and results in higher throughput.

  • We did NOT use in-memory caching! Again, this resulted in less contention for memory and allowed more clients to be serviced at the same time. Even though individual transactions were slower, we could service a lot more of them.

• Workflow and object state was stored in the database, not in-memory. We relied on SQL Server 2000 to locate and update the state of each workflow. If there is one thing DBMSs are good at, it is finding data FAST. This could also allow us to scale out easily, although the 10,000 transaction mark was achieved using a single server only. An added benefit was that we could create business process reports very easily and very quickly.

• Permissions and transformations were enforced at the database level. Each domain object was loaded using stored procedures that performed some complex joins between the object's tables, the permission tables and the view definitions. We relied on extensive indexing to make the process as fast as possible

• We did NOT use pessimistic locking! ONLY optimistic locking was allowed! Instead ...

• We used a two-level versioning system (major-minor versions) to ensure that each business process would work on its own copy of an object's data (minor version, e.g. 5.1), while allowing other clients to see the last published major version (e.g. 5.0). That also gave us long-running transactions, a really, really useful feature for business processes.

• Transactions were initiated at the highest level COM+ component. In essence, a new transaction was created each time a workflow action called a COM+ component. Even though this was very coarse-grained as COM+ back then only supported the Serializable transaction level, it did save us from blocking calls between components.

• If we had the time, we would have used MSMQ as well, moving to a message processing model. This would decouple the client and the workflow engine from the processing of requests domain object. This way we could also relax the Transaction-per-Call semantics.

How do the lessons of 2002 translate to a model driven platform with workflow in 2008?

• Use message passing and action messages insteand of direct modification of objects. Not only is it more scalable, it allows asynchronous and offline processing, and allows the creation of a Service Oriented Architecture.
  It also allows us to use fewer threads to service the same number of clients and workflows.
• Limit the connections to the database. Fewer concurrent connections mean fewer locks, fewer blocks, less delay in transaction processing.
• Use the database for workflow tracking. I am not sure that dehydrating and rehydrating a workflow is such a good idea from a scalability perspective.
• Use versioning or some other long transaction system to allow each business process to work on its own data.
• NO PESSIMISTIC LOCKING!

.NET 3.5 already offers several of the components needed to create a model driven platform. The various ORMs offer a great solution for the Data Layer. The dynamic languages will allow us to create and modify object actions, in a fully type-safe way even on the customer's site (try to do type-safe with VBScript). WF+ WCF offer the basics for building the rest of the platform, although WCF is not as easy to use for message processing as it could be. Fortunately, there are some great open-source solutions to this.
One of the best is NServiceBus, created by Udi Dahan. It offers essential functionality right out of the box, like different messaging models, publisher/subscriber support and long running transactions.

Of course, those are only a few of the services a full application platform needs. In fact, this is a great subject for discussion, which is why the second meeting of the Hellenic Architecture User Group will be about executable models and model-driven development. Some folks that have built model-driven platforms in the past have already promised to come. The date is not yet fixed, so please, join the Facebook group and propose a convenient date!

1st Greek Architecture User Group Meeting - Internet TV design lab

Following the example of the Portuguese Architecture Councils and the advice of several Architecture MVPs, some foolhardy folks decided to start a Greek Architecture User Group. Membership and attendance to the meetings will be open to anyone interested, although we may try to keep the design lab meetings small. The first meeting will be a design lab on Internet TV applications. The second meeting will probably cover Executable Models and Model Driven Development. It seems that there are some of us working on Internet TV right now, while others have developed executable model platforms as far back as 1995.

Quoting from Wikipedia, "Internet television (or Internet TV) is television distributed via the Internet. Internet television allows viewers to choose the show they want to watch from a library of shows. The primary models for Internet television are streaming Internet TV or selectable video on an Internet location, typically a website. It differs from IPTV in that IPTV offerings are typically offered on discrete service provider networks."

That definition can cover a lot of different applications. In our first meeting we will limit the discussion to two specific applications:

1. A Joost-like TV broadcasting application
2. A subscription service for educational videos and webcasts.

We will discuss the similarities and differences of the two systems in various layers of the system, from the video player to the media library management to system and broadcast quality monitoring.

An Internet TV architecture has to consider several factors:

1. Who are the users of the system? Are they the viewers, the media library administrators, the people doing the transcoding to the application's video format, advertisers that may want to create interactive advertisements, the program administrators that want to choose which videos are available to different customers at different periods, others that we will discover during our discussion?
2. Will the system support channels and how will they work? How is the program catalog created and how is it used? Should the catalog be personalized?
3. Will there be different subscription models? There could be a free package that includes a lot of advertisements, a paid Plus package with fewer advertisement and a Gold package with premium movies and series but no advertisements at all.
4. How is the media library managed? What are the metadata needed for each media entry that will facilitate the creation of catalogs and channels? What should a media entry include: the actual videos, trailers, photos and thumbnails, summaries, reviews? Media shoul also be marked according to genre, whether it is a new release, the actors,etc.
5. How flexible should the video player be? Should it be a separate application, like Joost or should it be embedded in a web site like Youtube? Maybe we want to present overlayed information like player statistics during a basketball game? Informational links during an educational video? Chat?
6. What is the necessary infrastructure? Can we use a P2P network? Do we use a service like ΑΚΑΜΑΙ? Do we only put the video on AKAMAI's network or do we upload the advertisements and the overlays as well?
7. Monitoring and operations is extremely important for a TV stations and is also important for an Internet TV station. How do we guarantee the smooth operation of the application? How do the operators detect that something may be wrong? How do they monitor and measure operations in order to plan future upgrades?
8. More technical matters: Silverlight 1.0, 2.0 or Flex? Do we need DRM? AKAMAI or LiveStation? Could we use both?

This is only a quick overview of the factors that should be considered when creating the architecture of an Internet TV application. We expect to go in greater depth during the Architecture User Group meeting.

The Portuguese Architecture Councils

This year, as in 2006, I was lucky enough to help at the Architecture Booth at Teched Developers. During my shifts, I had the opportunity to talk with fellow MVPs Paulo Morgado and Joao Martins, the winner of the 2006 Iron Architect contest as well as . I learned that in Portugal, they have 6 Architecture User Groups in various cities, with 6-10 members each. And that in a country with only 10 million people. Larger countries may have trouble organizing even one architecture council, but Portugal has 6! How did they do this?

  I think the secret is that each architecture council works in a very informal way. They hold monthly meetings where  someone either presents an application or system's architecture, or asks for help on a particular problem. The meetings are held in typical meeting rooms, where people can sit around a table and discuss the architecture or the problem at hand. There is no speaker at a podium, speaking to a large, silent audience.
  The various councils were also created in a rather informal way. The members of the first architecture council started meeting at Lisbon until some of them realized they came from neighbouring cities. Those members broke off and created their own local groups which grew until some of the members that came from the same city broke off and created their own council.

  Contrast this with another country, where people are trying to create one architecture council with limited success. The problem is that organizing the council meetings isn't easy. If you are going to invite many architects, you must make it worth their while. You must find an appropriate speaker, and that is not easy. As a result, the architecture council meetings are rather infrequent and the council is still straggling to take off.

I think the results prove which approach is best. Congratulations to Paulo, Joao and all the members of the Grupo de Arquitectura de Software Português! 

 

"Putting the User Back in Architecture" or face the consequences

At last, I found the time to get ready for Teched Developers 2007! I just started downloading the presentation slides and noticed the presentation "Putting the User Back in Architecture" by Simon Guest. This is a great presentation that reminds us what we often forget: The software is going to be used by users, but developers seldom take users into account when designing applications. The presentation covers many subjects: Identifying the users and their needs, designing an application that users find easy to use and finally, designing the application to handle failure gracefully. I'll concentrate on only two subjects.

The first is, identifying the users and THEIR needs. Not the needs the developer thinks they have but the users' actual needs. Quite often analysts or developers gather requirements or design applications without ever talking with the actual end users, thinking that they know what the users want. The end users get to see the application only late in the development cycle, during user acceptance testing or worse, when it is actually installed in their machine. Not surprisingly, users tend to have certain objections at this point. At best, developers discover that the application doesn't fit the users needs and get drowned in change requests - at a very late stage of the project. Know thy user, and you will avoid a lot of pain.

Another common failure is that customers, analysts and developers discuss what they think the application should do. They fail to discuss what is the purpose of the application. They discuss how it will work, not what it should do. It's like discussing how to build a bridge, or the techical specifications of a car, without asking what they are for! The result, as before, is that the application will have to change a lot when the users start using it and discover that it doesn't fit their needs.
A friend once asked me how long it would take to create a web site with dynamic pages that would display data from a database and video chat. This was the only information provided by the customer. Instead of giving an estimate, I told him to ask the customer what the site would be about. It turned out the customer wanted to create a dating site! Now that is a very different thing from "a dynamic web site with video chat".

It is vitally important that developers understand what the application's purpose is, if only as a survival measure! Knowing the application's purpose and the users needs, you can detect missing requirements and anticipate change requests. Change request will still come, but at least this way we can avoid the "Redesign the application one week before rollout" variety. In fact, we should be alarmed when we are asked to work on a project without knowing its purpose or the users. My experience is that we should demand to know the purpose of the application and contact with the customers to ensure what we are asked to build is what they really want.

The morale: Know thy users. Ask what the application is about, not how it will work.

Ίδρυση της Ελληνικής Εταιρείας Τεχνολογίας Λογισμικού

Έλαβα το παρακάτω email από τον Διομήδη Σπινέλλη, editor του IEEE Software και συγγραφέα βιβλίων όπως το Code Reading και Code Quality. Συμφωνώ απόλυτα με την ιδέα και προτείνω σε όσους ενδιαφέρεστε για Software Engineering να συμμετέχετε και εσείς. Το μόνο που χρειάζεται είναι να μπείτε στο wiki και να προσθέσετε το όνομα σας και ένα email.

---------------------------------------------------------------------------------------------

Σε μια μικρή ανεπίσημη συνάντηση που πραγματοποιήσαμε κάποιοι συνάδελφοι
στις 7 Ιουνίου στη Θεσσαλονίκη, συζητήσαμε το ενδεχόμενο σύστασης
επιστημονικού σωματείου με αντικείμενο την τεχνολογία λογισμικού.
Πιθανός τίτλος θα μπορούσε να είναι Ελληνική Εταιρία Τεχνολογίας
Λογισμικού (ΕΛΕΤΕΛ).

Στη συνάντηση είχαμε ακόμα μιλήσει για το ενδεχόμενο να πραγματοποιηθεί
μια εναρκτήρια ημερίδα σε συνδυασμό με ομιλητές που θα συμμετάσχουν στο
ετήσιο board meeting του IEEE Software που θα γίνει στην Αθήνα, 20-23
Μαΐου 2008.

Για να οργανωθούμε έχω δημιουργήσει ένα wiki στον ιστότοπο
<http://istlab.dmst.aueb.gr/eletel>.  Παρακαλώ επισκεφθείτε το (ιδανικά,
ανοίξτε και λογαριασμό για να ξέρουμε ποιος γράφει τι) και συμπληρώστε
στοιχεία συναδέλφων που θα θέλατε να προσκαλέσουμε ως ιδρυτικά μέλη
(ένας αρχικός γύρος συλλογής που έγινε από αυτούς που είχαν συμμετάσχει
στην πρώτη συνάντηση, είχε ανέλπιστη ανταπόκριση και κατέληξε στη
συγκέντρωση 48 ονομάτων).  Για να μη ξεχάσουμε κανέναν, δώστε έμφαση σε
συναδέλφους που ξέρετε πως είναι ενεργοί στο συγκεκριμένο χώρο, καθώς
και σε συναδέλφους του δικού σας οργανισμού ή οργανισμών που δεν έχουμε
περιλάβει.  Επίσης, μπορείτε να συμπληρώστε τις υπόλοιπες σελίδες ή να
δημιουργήστε σελίδες που πιστεύετε πως χρειάζονται.  Αν δε σας
ενδιαφέρει η συγκεκριμένη προσπάθεια μπορείτε να διαγράψετε το όνομά σας
από τη σελίδα με τα ιδρυτικά μέλη, ή να μου στείλετε ένα μήνυμα να σας
διαγράψω εγώ.

Σε μια εβδομάδα θα στείλω ένα τελευταίο μήνυμα σε όλους όσους έχουν
προταθεί ως ιδρυτικά μέλη για να συμπληρώσουν ΟΚ πλάι στο όνομά τους.
Από εκεί και μετά θα ξεκινήσουμε την επίσημη διαδικασία της ίδρυσης του
σωματείου και την οργάνωση της εναρκτήριας ημερίδας.

Φιλικά,

Διομήδης Σπινέλλης

 

Steve McConnell blogs!

We all know Steve McConnell, from his extremely useful books like "Code Complete" and "Software Estimation". Most of us also wondered in the past, why does Steve McConnell not have a blog? Well, now he does at "10x software development".

His latest post, "Is Faster Always Faster?" addresses the intriguing fact that technological advances do not always lead to productivity advances, even in software development! Boy, ain't that the truth! I rediscover that fact each time I find myself spending 10 times the effort to create a diagram in a UML tool than I would drawing on a whiteboard!

Κι όμως, υπάρχουν εξαιρέσεις!

Συζητήσαμε πρόσφατα στο "Δεν υπάρχουν απόφοιτοι?" για τους έλληνες απόφοιτους, οι οποίοι βγαίνουν στην αγορά με ελλιπείς (συχνά) γνώσεις, χωρίς υποστήριξη από τις σχολές τους και έχοντας συχνά άγνοια του τί σημαίνει αγορά πληροφορικής. Ένα από τα πιο ενδιαφέροντα σημεία ήταν ότι οι καθηγητές δεν ενδιαφέρονται να προωθήσουν τους φοιτητές, δεν τους παρουσιάζουν τις νέες (έστω τις τρέχουσες) τεχνολογίες. Η συμμετοχή από ελληνικά πανεπιστήμια στους φοιτητικούς διαγωνισμούς του IEEE Computer Society και του Imagine Cup της Microsoft είναι απογοητευτική. Όχι όμως επειδή δεν ενδιαφέρονται οι φοιτητές. Το αντίθετο μάλιστα. Υπάρχουν πολλοί φοιτητές οι οποίοι θα ήθελαν να συμμετέχουν στους διαγωνισμούς αλλά δεν μπορούν να βρουν ούτε ένα επιβλέποντα καθηγητή στη σχολή τους.

Ευτυχώς όμως που υπάρχουν και οι εξαιρέσεις!

• Σήμερα γίνεται το 4ο φοιτητικό συνέδριο του Τμήματος Διοικητικής Επιστήμης και Τεχνολογίας του Οικονομικού Πανεπιστημίου, με θέματα κατά πολυ πιο ενδιαφέροντα από τα περί "ανάπτυξης της ευρυζωνικότητας στο Νέο Άνω Νευροκόπι" στα οποία μας έχουν συνηθίσει τα "επίσημα" συνέδρια του χώρου.
• Η συμμετοχή στο φετεινό Imagine Cup είναι μεγάλη, ακόμα και από ομάδες φοιτητών οι οποίες δεν βρήκαν καθηγητές. Ακούω μάλιστα ότι κάποιοι καθηγητές είχαν περισσότερες προτάσεις απ' όσες μπορούσαν να αναλάβουν.
• Και το καλύτερο? Ακούω ότι θα κατέβει φέτος μία ομάδα, σε ένα πρωτάθλημα πολύ ειδικό και εξαιρετικά ενδιαφέρον. Ο προπονητής έχει όλα τα προσόντα να γίνει άλλος ένας Ρεχάγκελ.

Αναρωτιέμαι πάντως, μήπως θα έπρεπε να βοηθήσουμε κι εμείς τους καθηγητές και τους φοιτητές που ενδιαφέρονται? Φέτος είναι αργά, αλλά του χρόνου σίγουρα θα μπορούσαν επαγγελματίες προγραμματιστές να αναλάβουν την επίβλεψη όσων φοιτητικών ομάδων δεν μπόρεσαν να βρουν επιβλέποντες καθηγητές. Εξάλλου τα κριτήρια των διαγωνισμών είναι η πρωτοτυπία, η σωστή σχεδίαση, η σωστή οργάνωση των ομάδων, η πραγματοποιησιμότητα των προτάσεων. Πράγματα στα οποία ένας επαγγελματίας μπορεί να βοηθήσει το ίδιο καλά όπως και ένας καθηγητής.

Όσο για τις ομάδες μας, καλή επιτυχία και πρώτη θέση στο παγκόσμιο. Και μην ξεχνάτε. Βαρονούσηδες που 'ναι ετουτοινέ οι Ρωμαίοι!

CAB to become part of .NET Framework ?

I was looking recently at the Patterns & Practices roadmap when I noticed that there would be no new version of the Composite Application Block because ... it will be included in a future version of the Framework! Now that is great news!

 

For people who don't know what CAB is, it's a framework similar to Struts or JSF for building smart client (i.e. desktop) applications. It implements a variation of the MVC pattern, the MVP (Model-View-Presenter) with the ingenious addition of use cases in the form of WorkItems. CAB allows applications to be composed of different application modules. Each module can represent a completely different application scenario, e.g front office or analytics and it may implement different use cases as WorkItems and include its own UI elements (views). The main application acts as a shell that provides common functionality and composes the UI elements of the modules. It also routes UI commands and events to the proper modules, handles offline operation and configuration.

 

Configuration plays an important role in CAB. It specifies which modules should be loaded by the application. This means that an application can provide different functionality to different users just by modifying a configuration file. Or, that a new module can be added just by deploying its assembly and modifying the configuration. The main application doesn't need to know about the new modules at compile time. And, once you store the configuration in the database, you can have dynamic, per user configuration without deploying the configuration to the clients. That's nice!

 

Until recently, if anyone wanted to create a baseline application platform he would have to invent a lot. How to define the application's entities, handling persistence, how to define the business processes and finally, how to present everything to the client and do it all dynamically. CAB now takes care of the client-side concerns and it looks that soon, .NET framework will do so as well.

I like it!

Ο Sql Server ΔΕΝ ΧΡΕΙΑΖΕΤΑΙ κόλπα για να υποστηρίξει τα ελληνικά!

Έχω προσέξει τελευταία ότι η ερώτηση που απαντάω πιο συχνά στο dotnetzone ή στη δουλειά είναι "Τί χρειάζεται για να περάσω ελληνική ηµεροµηνία/αριθµό στον Sql Server/στο .NET/στη VB6 ?" ή η παραλλαγή της "O Sql Server είναι στα αγγλικά και το PC στα ελληνικά. Τί να κάνω?". Και το επιστέγασµα όλων "Έγραψα ελληνικά στον Sql Server και τώρα µου γυρίζει ερωτηµατικά. Τί πρέπει να κάνω?".

Και η απάντηση σε όλα τα παραπάνω είναι ΤΙΠΟΤΑ! Σε όλες τις περιπτώσεις τα προβλήµατα εµφανίστηκαν επειδή κάποιος έκανε κάποιο λάθος προσπαθώντας να "διορθώσει" τη συµπεριφορά του Sql Server ή της VB6 ή του .NET.

Ας πάρουµε τα πράγµατα µε τη σειρά ξεκινώντας µε την ευκολότερη ερώτηση: Πως αποθηκεύουµε ελληνικά/ινδικά/φαρσί σε αγγλικό/νιγηριανό/ρωσικό Server? Απλά αποθηκεύοντας σε πεδία nchar/nvarchar/ntext. Τα πεδία αυτά είναι φτιαγµένα για να αποθηκεύουν strings σε Unicode. Εντωµεταξύ, η VB6 και φυσικά το .NET χρησιµοποιούν Unicode για όλα τα strings τους οπότε δεν υπάρχει κανένα πρόβληµα µετατροπής µεταξύ VB6 ή .NET και Sql Server. Αν κάνουµε σωστή δουλειά και χρησιµοποιούµε stored procedures ή έστω parameterized queries η ιστορία τελειώνει εδώ. Αν θέλουµε όµως να τεστάρουµε κώδικα στα γρήγορα και δηµιουργούµε το Sql statement µε string concατεnατionσ, πρέπει να θυµηθούµε να βάλουµε και ένα N µπροστά από κάθε string.

Τα προβλήµατα εµφανίζονται όταν αποθηκεύουµε σε πεδία varchar, ή αντιγράφουµε δεδοµένα varchar µεταξύ Server µε διαφορετικές γλώσσες ή µέσω εφαρµογής που τρέχει σε άλλη γλώσα. Αυτά τα πεδία είναι ASCII και χρησιµοποιούν συγκεκριµένα codepage . By default, ο Sql Server θα προσπαθήσει να µεταφράσει τα strings που του έρχονται στο κατάλληλο codepage αλλά τί µπορεί να κάνει αν δεν υπάρχει αντιστοιχία µεταξύ ελληνικών και ρουµανικών χαρακτήρων? Πέρα από το να βάλει ένα ? στη θέση του προβληµατικού χαρακτήρα, όχι πολλά.

Κι ερχόµαστε στο ελαφρώς πιο ενδιαφέρον θέµα των δεκαδικών και των ηµεροµηνιών. Εφόσον χρησιµοποιούµε stored procedures ή parameterized queries για να περάσουµε τιµές τύπου date, double, decimal κλπ. δεν θα εµφανιστεί κανένα πρόβληµα. Αν όµως τεµπελιάσουµε και "χτίσουµε" το Sql statement µε concατεnατionς είναι πολύ πιθανό να έχουµε πρόβληµα. Αυτό συµβαίνει επειδή η εφαρµογή µας θα µετατρέψει τους αριθµούς ή τις ηµεροµηνίες σε string χρησιµοποιώντας τις ρυθµίσεις του χρήστη που την εκτελεί. Αν αυτές διαφέρουν από τις ρυθµίσεις του Server, ο καηµένος ο Server δεν θα ξέρει τί να το κάνει το Sql statement ! Για φανταστείτε, στη µέση ενός where statement να βρεθεί ξαφινκά ένα κόµµα. Ή µία διεύθυνση 1/11/2005. Αυτό τώρα τί είναι, 1η Νοέµβρη ή 11η Gενάρη?

Αν βέβαια χρησιµοποιούµε παραµέτρους δεν έχουµε κανένα πρόβληµα. Αν όµως θέλουµε ντε και καλά να φτιάξουµε το Sql statement σαν string, πρέπει να ακολουθήσουµε κάποιους κανόνες.
Καταρχήν, περνάµε τα αριθµητικά δεδοµένα πάντα χρησιµοποιώντας την τελεία ως υποδιαστολή. Στην VB6 αυτό επιτυγχάνεται µε το function Str(). Αυτό είναι ίσως και το µόνο σηµείο όπου πρέπει να χρησιµοποιούµε την Str() αντί για την CStr(), η οποία λαµβάνει υπόψη της ρυθµίσεις του χρήστη.
Δεύτερον, δεν αφήνουµε ποτέ στην τύχη την µετατροπή των ηµεροµηνιών σε string. Φροντίζουµε πάντα να τις µετατρέπουµε στη µορφή 'yyyyMMdd' το οποίο είναι ένα από τα δύο τα οποία είναι εγγυηµένο ότι θα τα καταλάβει σωστά ο Sql Server. Το άλλο είναι η µορφή {d yyyy-MM-dd} (χωρίς εισαγωγικά) η οποία απλά απαιτεί µερικούς χαρακτήρες παραπάνω χωρίς να προσφέρει κάτι. Τις µετατροπές αυτές µπορούµε να τις πετύχουµε µε την Format στην VB6 ή την τostring("yyyyMMdd") στο .ΝΕΤ.

Ποιό είναι το συµπέρασµα? Ότι µπορούµε να περάσουµε νούµερα και ηµεροµηνίες εύκολα στον Sql Server χωρίς να κάνουµε τίποτα!

On Error Resume ... what?

    Imagine a form. A VB6 form. The form has a couple dozen controls. It also has a couple dozen methods. Each method has a couple hundred lines of code (net, no comments). Each method may call a half dozen other methods, except some thousand-liners that call almost half of all the methods.

 

And there is no centralized error handling.

 

    Nothing. Nada. Zip. In fact, there is no real error handling code at all. Each method returns either an exit code or a default value. Their callers have to check the return codes or guess whether the default return value is a normal value or the result of an error. Some may even return error messages instead of codes. And while the programmers were generally quite diligent in checking the result codes, some error conditions  inevitably go unnoticed. Until a customer notices them, that is.

    Now, the methods do log the errors before returning the error codes. Only, they don't all do it the same way. Some log their names and the error description, others just a generic error message. Few do log the source of the error. For the thousand liner methods, this means that it is almost impossible to locate where the error occurred!

 

    Now, the programmers should make sure they always check the return values. They should always log all the appropriate error info. And they should always return the agreed-upon result codes. But people make mistakes. They can't help it. There will always be some unchecked return values and what happens then? The necessary cleanup code isn't executed, invalid values are produced. At best, this will cause the code to throw another error later on, only the root cause will be unknown. Usually , the incorrect results will travel all the way to the end user, resulting on some quite entertaining expletives from the end user and some rather unflattering comments regarding the programmers' ancestry. At worst, the invalid results may we go unnoticed and result in significant financial losses and legal trouble.

    Have you ever heard about the granny that was charged 50,000 € for electricity? Or the guy that bought a new stereo for only 3.00 €? Would you like to be the customer whose bank account was deleted when he deposited just enough to cover his overdraft?

 

Would you feel safe using that code? Or, maybe even modify it to add new functionality?

Coming soon ... "The Architecture that Wasn't!"

I have a blog post in mind. The title will be “The architecture that wasn’t”, or something along those lines. The subject, is a very popular architecture (a full system architecture, not just a description of the data access mechanism), which is widely used in Greece as well. Only thing is, it has some very strange characteristics:

• It has been successful for over a decade
• Whoever uses it in Greece, thinks he is the only one to do so.
• When they learn that others use it they go into shock.
• Most of the companies using it outside Greece tend to be quiet about it.
• It allows the creation of completely new applications in months (~6 months for complex enterprise level apps).
• People who don’t use it think it is impossible, even when they see the apps running before their eyes.
• People who do, can’t understand why the rest of the world doesn’t. After all, they can create new apps in months!
• Microsoft offers the tools for it almost for free. Next year, it will be almost totally free.

And then, I think we should have a community event about it, or better yet, a full-blown DevDays event, where the people from the companies that do use it will present their implementations, the different services and facilities they provide and the problems they faced in the past. I know of at least 4 Greek companies that use this architecture, and I’m certain there are a lot more.

If anything else, this way we may no longer hear how everything must be coded in the forms because we have no time for architecture and anyway architecture is only for Microsoft and banks and the business environment in Greece doesn’t allow us to do a proper architecture and it would be good to have it but impractical  …

The usual litany.

I would like some help though, as I’m not very happy with the title yet. If you have a better one, please, speak up!

Debugging ... With a fishbone!

Sounds familiar? The customer reports a problem that can't be reproduced. No errors were logged and no error messages generated. No-one can go to the customer's site for at least a day. All we have to work with are the symptoms reported by the customer and the source code. How do we find the bug with so little information ?

Sounds a bit like a detective novel, right? Like an episode from "Without a trace", the missing persons investigation series, maybe?  Well, if it sounds like a detective mystery and feels like a detective mystery, why not handle troubleshooting like a detective mystery as well?

Indeed, there are significant similarities between troubleshooting and searching for a missing person. There is scant forensic evidence (no error logs or messages) and unreliable witness accounts (the customers' reports). Sometimes, the absence of a fact is a fact in itself (no error logs means the error logging code wasn't called). But it is not proof (the absence of error messages is not proof of the absence of errors).

We also have a powerful tool that the detectives lack. We have the source code, which allows us to re-enact the crime (oops, I mean the program’s execution) to check our hypothesis.  But what happens when the code is unfamiliar or convoluted, and we can’t reproduce the effects described by the customers? We can read the code and identify the spots where something should or shouldn’t happen, but things can get very confusing, very fast. OK, why not copy one of the tools of the detectives of “Without a Trace”?

Many of you may have noticed the fishbone-diagram the detectives draw with each event from the moment a person goes missing, drawing a diagonal line for each significant event and action of the victim and the witnesses. This is a variation of the Cause and Effect or Ishikawa diagram, which is also called, guess what? The fishbone diagram! In the fishbone diagram, we write the facts in the “head”. From it, we draw a horizontal line. From this horizontal line we start drawing diagonal lines for each of the major probable “causes” that may lead to the described effects. For better legibility, we alternate the diagonal lines above and below the main horizontal line. That leads to the characteristic fishbone shape. We can keep analyzing the causes, alternating horizontal and diagonal lines, as seen on the figure below.

At some point we may uncover a cause that we can verify that it has happened. In this case, we erase the cause and add it as a fact to the head. Perhaps, we discover that executing a specific branch of the code results in some information log entries, and the customer verifies that the entries do exist. Great! We have just discovered a new fact! Or we may discover that all error handling code generates error messages. That, in conjunction with the fact that no error messages have been generated, means that the error handling code was never called. So, perhaps we have an On Error Resume Next? A Failure return value is ignored?

So, how can we use the fishbone diagram to troubleshoot an elusive problem? First, we add the “facts” we know to the head of the fishbone. In our case, these are that no export files appeared, there were no error logs and no error messages. Then, we add the major cause categories. These should include user error (the user was looking at the wrong folder), environment causes (database server down?) as well as the methods that are executed when the problem occurs (the Export method). The fishbone diagram below shows quite a few cases in red that could result in no exported files and no error messages. What if the dataset we read from the database is empty? What if we fail to handle row processing errors? What if we use On Error Resume Next in VB code, and fail to check the error codes?

For the record, the customer had indeed made a mistake and looked in the wrong export folder. Checking the code using the fishbone diagram, though, helped identify several possible failure points in the code that could cause the same or similar problems in the future.

Remoting and Logging and Enterprise Library, Oh My!

I've been bitten by an almost undocumented bug of the Enterprise Library Logging Application Block. I have created a service that exposes an object through remoting for clients to call. The service uses the Exception Handling and Logging blocks throughout the code. Now, when a client calls the remote object, he gets a TargetInvocationException on top of an InvalidCastException. The object code has thrown no exceptions, logging works as expected, the method calls finish properly, but still the client gets an exception! The exceptions stop when I remove the logging code, but I can't very well replace the logging infrastructure of the service!

After a lot of stepping into code, re-checking my app.config files, googling for over two days, I came accross Keenan Newton's  article, Logging Application Block and Remoting . It seems that the way the Logging Block implements tracing writes something to the CallContext which doesn't serialize all that well. The quick solution is to disable tracing (just go to the Logging Application Block node and set TracingEnabled to false).
Thanks, Kean!

Perhaps, a better solution would be to create a remoting filter on the client or the server to remove the extra info added by the Logging block. Or even better, Microsoft fixes the Logging block so it works with remoting.

How I stopped worrying and learned to love Interop!

Για κάποιο λόγο (μή ρωτάτε γιατί) τον τελευταίο καιρό είμαι υποχρεωμένος να καλώ ActiveX dlls στα οποία πρέπει να περάσω ADO connections. Η εμπειρία δεν μπορώ να πω ότι ήταν και η πιο ευχάριστη. Βλέπετε, όταν βάζει κανείς reference σε ένα activex dll το οποίο δέχεται π.χ. παραμέτρους Connection το Visual Studio θα βρει και θα προσθέσει το κατάλληλο Interop assembly (adodb.dll). Το assembly αυτό βρίσκεται κανονικά στο C:\Program Files\Microsoft.NET\Primary Interop Assemblies. Έλα όμως, που δεν θα το προσθέσει και στο Deployment Project! Αυτή ήταν η κανονική λειτουργία στο Visual Studio 2003 (http://support.microsoft.com/kb/321688/en-us) αλλά όπως φαίνεται είτε άλλαξε, είτε εμφανίστηκε ένα bugάκι. Θα μου πείτε, κανένα πρόβλημα, αφού τα αρχεία θα υπάρχουν στους υπολογιστές των client...

Αμ δε! Σε κάποια μηχανήματα, παρότι εγκαθίσταται κανονικά το .NET 2.0 runtime, το folder με τα Interop Assemblies δεν δημιουργείται! Ίσως φταίει ότι τα μηχανήματα αυτά ήταν Windows 2003 Server, ίσως όχι. Όπως και να έχει, μετά από πολύ ψάξιμο, και αφού βρήκα και αυτό το ωραίο αρθράκι με τα προβλήματα του ADODB Interop (http://support.microsoft.com/kb/910696/en-us) άρχισα να πιστεύω ότι ίσως το Interop να μην είναι και τόσο καθαρή δουλειά όσο ακουγόταν στην αρχή. Κάτι το DLL Hell, (τί κάνεις αν εσύ χρησιμοποιείς μία version των dll, και τα μηχανάκια παλαιότερη?), κάτι τα bugάκια του Deployment Project, κατέληξα στο συμπέρασμα ότι ο μόνος τρόπος να βεβαιωθείς ότι θα δουλέψει ο κώδικας σου είναι να το δοκιμάσεις σε διαφορετικά PC τα οποία θα μοιάζουν όσο το δυνατόν περισσότερο με τα μηχανήματα στα οποία θα κάνεις deploy.

 Είναι σίγουρα πολύ φασαρία, αλλά είναι και η μόνη λύση αν δεν θέλει κανείς να εξηγεί στον πελάτη γιατί η εφαρμογή πετάει περίεργα exceptions! Ας είναι καλά το Virtual PC και το VM Ware!

Hola from Teched Barcelona!

Yes! For once, I managed to arrive at a Teched conference on time! I finally came in ahead of the hordes at the registration desk, with plenty of time to look around the exhibition hall, find the proper session room in time and at a leisurely pace AND have a coffee before the session starts! And write about it of course [:)]. The weather here in Barcelona is really nice, sunny, 18 C. The city is great, as always. The conference center huge. The exhibitors great (including Ivar Jacobson Consulting, Jetbrains, DevExpress).

And I'm slightly anctious. You see, I've been studying everything I could find on SQL Server 2005 for over a month so that I wouldn't appear totally incompetent when answering questions at the SQL Server pavillion. And on Friday, I learn that I'm scheduled to work at the Architecure pavillion! Not only that, I'm also scheduled to interview a really interesting guy from Microsoft's Connected Systems Division! Wow, am I flattered and all that, but a tiny bit of early warning would be great!

Oops, time for the first session of the preconference seminar, "Becoming an architect"!

Vodafone, ασφάλεια και εξωγήινες απαγωγές.

Διάβασα το άρθρο του Διομήδη Σπινέλλη για τη σχεδίαση των τηλεφωνικών κέντρων της Vodafone και μπήκα σε σκέψεις. Όπως φαίνεται, τα φοβερά τηλεφωνικά κέντρα δεν είναι παρά μηχανήματα server που τρέχουν Solaris και κάποιες εφαρμογές. Παρότι θα περίμενε κανείς τα μηχανήματα αυτά να έχουν ειδικές προδιαγραφές ασφαλείας, αποδεικνύεται ότι είναι απλά συστήματα, με τις συνηθισμένες δυνατότητες ασφαλείας. Ακόμα και αυτές οι δυνατότητες να είχαν χρησιμοποιηθεί όμως, κάποιο ίχνος του δράστη θα είχε μείνει!

Ακόμα και ένα μηχανάκι Windows NT, κι ένα bare-bones Linux, έχει κάποια στάνταρ πράγματα. Έχει user και permissions, έχει logs, έχει policies. Σε περιβάλλον δικτύου, και με ένα στοιχειώδες administration, τα events των μηχανημάτων στέλνονται σε ένα κεντρικό log, ενώ αν γίνει λίγο καλύτερη δουλειά ελέγχεται και το τί εγκαθίσταται στα μηχανήματα. Σε σοβαρά εταιρικά δίκτυα υπάρχουν και εφαρμογές Intrusion Detection οι οποίες αναλύουν συνέχεια τα logs και ειδοποιούν όταν εντοπίζεται ύποπτη συμπεριφορά. Σε ένα server τηλεφωνικού κέντρου τώρα, θεωρείται δεδομένο ότι γίνεται συνεχής έλεγχος των κλήσεων και η κεντρική καταχώρηση τους. Αν δεν γινόταν αυτό, θα ήταν αδύνατη η χρέωση των τηλεφωνημάτων. Οπότε? Χάθηκε να ελέγχουν και τα security logs?

Αφήστε το άλλο. Και τα NT και τα απλούστερα UNIX ρυθμίζονται άνετα για να εμποδίσουν οποιονδήποτε παρείσακτο να κάνει login και να κάνει πράγματα για τα οποία δεν είχε δικαίωμα. Είναι οι δυνατότητες που παλαιότερα ονομάζονταν C2 και σήμερα Common Criteria. Δεν μιλάμε για hacking μέσω δικτυακής σύνδεσης, αλλά να πάει κάποιος στο μηχάνημα και να προσπαθήσει να μπει χωρίς άδεια. Δεν γίνεται. Εκτός δηλαδή και το κλείσει και πάρει τον σκληρό και τον βάλει σε άλλο μηχάνημα. Αλλά αυτό θα γινόταν ελαφρώς αντιληπτό νομίζω.

Οπότε? Τί μπορεί να συνέβει, έτσι ώστε να μην υπάρξει κανένα audit event, ώστε να τροποποιηθούν αρχεία και κανείς να μην καταλάβει τίποτα? Αν αυτό συνέβαινε σε κάποιο γραφείο, θα έλεγα ότι κάποιοι είχαν τα ίδια root/administrator password για όλα τα μηχανήματα, δεν χρησιμοποιούσαν security policies, δεν είχαν ή δεν κοίταζαν τα security logs. Θα υπέθετα ότι και ένας φοιτητής ακόμα θα μπορούσε να πειράξει ένα τέτοιο σύστημα και να τη γλυτώσει. Όχι "ξένες δυνάμεις"! Για τα τηλεφωνικά κέντρα, τί να υποθέσω?

Για τις όλες τις εφαρμογές που αναπτύσσουμε παρακάμπτοντας οποιαδήποτε απαίτηση ασφάλειας, τί να υποθέσω? (Έλα μωρέ, ποιός χρειάζεται ασφάλεια?) Δύο-τρία πράγματα να κάνει κάποιος και μπορεί να προστατεύσει τις εφαρμογές του από τις πιο συχνές μορφές επίθεσης. Δεν απαιτώ η εφαρμογή μου να τρέχει ως admin. Δεν συνδέομαι στη βάση ως dba. Δεν δίνω στο connection που θα χρησιμοποιήσω περιττά permissions. Κρατάω κι εγώ ένα audit log.

Και μετά γκρινιάζουμε για το security των Windows …

Νέο βιβλίο από το Διομήδη Σπινέλλη

Βγήκε το νέο βιβλίο του Διομήδη Σπινέλλη, του συγγραφέα του "Code Reading, The Open Source Perspective". Το βιβλίο λέγεται   "Code Quality, The Open Source Perspective" και ο εκδότης είναι η Addison-Wesley. Το πρώτο βιβλίο ήταν το πρώτο το οποίο ασχολήθηκε με την ανάγνωση κώδικα αλλά και τη συγγραφή κώδικα έτσι ώστε να είναι πιο αναγνώσιμος και εύκολα αναγνωρίσιμος. Το νέο βιβλίο καλύπτει τους διάφορους τομείς που επηρεάζουν την ποιότητα του κώδικα. Καλά, θα πείτε, ούτε το πρώτο ούτε το τελευταίο βιβλίο είναι το οποίο ασχολείται με το θέμα. Η διαφορά?

Χρησιμοποιεί  πραγματικά παραδείγματα! Όχι "ωραιοποιημένο" κώδικα, όχι απλά samples, αλλά κώδικα από τον Apache, το BSD Unix και την HSQLDB!

Οπωσδήποτε μπαίνει στη λίστα με τα βιβλία που θα διαβάσω!

Πως να (μην) μειώσετε τη μνήμη που τρώει η εφαρμογής σας.

Eδώ και καιρό κυκλοφορεί σε διάφορα forum μια αμφιλεγόμενη τεχνική για τη μείωση της μνήμης που χρησιμοποιεί μια εφαρμογή. Η τεχνική αυτή βασίζεται στη χρήση του function SetProcessWorkingSet για να "ελευθερώσει" τη μνήμη που χρησιμοποιει. Αυτό που γίνεται ουσιαστικά, είναι ότι οι σελίδες της εφαρμογής που βρίσκονται στη μνήμη γράφονται στο pagefile και αφαιρούνται από τη μνήμη. Η εφαρμογή εξακολουθεί να χρησιμοποιεί την ίδια μνήμη συνολικά, στον Task Manager όμως θα φαίνεται σαν να χρησιμοποιεί λιγότερη RAM. Ενώ πριν η εφαρμογή φαινόταν να χρησιμοποιεί 10MB τώρα χρησιμοποιεί 2MB. Αντί όμως να αυξηθεί η ταχύτητα της εφαρμογής, βλέπει κανείς μια σημαντική καθυστέρηση! Τί έγινε?

Η κλήση στην SetProcessWorkingSet αναγκάσε τα Windows να βγάλουν από τη RAM σχεδόν όλες τις σελίδες που αφορούν την εφαρμογή. Οι σελίδες αυτές όμως δεν περιείχαν μόνο τις μεταβλητές της εφαρμογής αλλά και τα DLL που χρησιμοποιούσε, μεταξύ των οποίων είναι και τα DLL του .NET Framework. Όταν λοιπόν η εφαρμογή προσπαθήσει να κάνει ένα απλό redraw ή να ανταποκριθεί σε ένα mouse click, θα πρέπει να φορτώσει ξανά από την αρχή στη RAM τις σελίδες με τις μεταβλητές και τα DLL! Αυτό μπορεί να το διαπιστώσει κανείς αν προσθέσει στον Task Manager τη στήλη Page Fault Delta, η οποία δείχνει πόσα page faults έγιναν από την τελευταία ανανέωση. Και μετά, ας μετακινήσει το παράθυρο της εφαρμογής στην οθόνη. Ενώ πριν από την κλήση στην SetProcessWorkingSet το page fault delta είναι συνήθως 1 ή 0, μετά την κλήση γίνεται 600-900! Αμάν! Για ένα redraw γίνονται 600 page faults?! Μετά από λίγο πάντως, η χρήση της μνήμης θα επανέλθει στο αρχικό επίπεδο καθώς θα φορτωθούν ξανά όλες οι σελίδες μνήμης που είχαν φορτωθεί και στην αρχή.

Η τεχνική αυτή μπορεί να φανεί χρήσιμη σε μία μόνο πολύ περιορισμένη περίπτωση. Αν είμαστε σίγουροι ότι η εφαρμογή μας δεν θα χρησιμοποιηθεί για μεγάλο διάστημα, μπορούμε να καλέσουμε την SetProcessWorkingSet για να μεταφέρουμε στο pagefile όσο περισσότερες από τις σελίδες μνήμης χρησιμοποιεί η εφαρμογή έτσι ώστε να έχουμε διαθέσιμη RAM για κάποια άλλη βαριά εφαρμογή. Αυτό ακριβώς κάνουν και τα Windows όταν κάνουμε minimize μια εφαρμογή. Καλούν την SetProcessWorkingSet προκειμένου να υπάρχει περισσότερη διαθέσιμη μνήμη για τις εφαρμογές που εξακολουθούν να τρέχουν στο foreground.

Μεγάλη ευθύνη για την παρανόηση σχετικά με την SetProcessWorkingSet έχει και ο Task Manager, ή μάλλον όποιος αποφασίζει για τα ονόματα των δεικτών μνήμης που χρησιμοποιεί ο Task Manager. Αυτό που ο Task manager αποκαλεί Memory Usage είναι στην πραγματικότητα το Working Set, το οποίο περιέχει και σελίδες μνήμης οι οποίες χρησιμοποιούνται από πολλές εφαρμογές, όπως τα DLL του .NET Framework! Περισσότερα όμως για το τι σημαίνουν πραγματικά οι δείκτες και πως μπορείτε βρείτε πόση μνήμη χρησιμοποιεί στην πραγματικότητα μια εφαρμογή θα βρείτε στο προηγούμενο άρθρο, «Μα πού πήγε η μνήμη μου?»

Μα που πήγε η μνήμη μου?

Φτιάχνω μια ωραία, μικρή εφαρμογή σε .NET η οποία εμφανίζει ένα απλό Hello World και δύο κουμπάκια, την τρέχω και κοιτάζω στον Task Manager πόση μνήμη χρησιμοποιεί. Και τί βλέπω? Η μικρή εφαρμογή χρησιμοποιεί 10 MB! Μα είναι δυνατόν? Μήπως όλες οι εφαρμογές .NET είναι μνημοβόρα τερατουργήματα?

Φυσικά η κατάσταση δεν είναι τόσο τραγική. Για να καταλάβει κανείς τί συμβαίνει θα πρέπει να καταλάβει τί σημαίνουν πραγματικά οι ενδείξεις του Task Manager και πως διαχειρίζονται τη μνήμη τα Windows. Όταν ξεκινάει μια εφαρμογή, τα Windows φορτώνουν στη μνήμη το exe της εφαρμογής αλλά και τα DLL, αν αυτά δεν έχουν ήδη φορτωθεί στη μνήμη. Επίσης, δίνουν ένα χώρο στη μνήμη για να δημιουργεί τις μεταβλητές της. Τώρα, αν τα DLL έχουν ήδη φορτωθεί από κάποια άλλη εφαρμογή, τα Windows δεν θα τα ξαναφορτώσουν αλλά θα χρησιμοποιήσουν τα DLL που υπάρχουν ήδη στη μνήμη. Τα bytes αυτά τα οποία μπορούν να μοιραστούν μεταξύ εφαρμογών ονομάζονται shared bytes. Τα bytes που αφορούν αποκλειστικά την εφαρμογή και δεν μοιράζονται με άλλα processes ονομάζονται ... private bytes. Όλα αυτά τα bytes δεν βρίσκονται συνέχεια στη RAM. Μόνο ένα υποσύνολό τους βρίσκεται κάθε στιγμή στη RAM ενώ τα υπόλοιπα βρίσκονται στο pagefile. Το σύνολο της RAM που χρησιμοποιεί κάθε στιγμή μία εφαρμογή λέγεται Working Set της εφαρμογής.

Και εδώ είναι το κόλπο. Το Working set περιλαμβάνει ΚΑΙ private bytes ΚΑΙ shared bytes! Από τα 10ΜΒ που πιάνει η εφαρμογούλα μου, τα 8ΜΒ είναι shared bytes!

Μα καλά, θα πείτε, γιατί ο Task Manager δείχνει memory usage 10ΜΒ? Γιατί ο Task Manager περιγράφει τα ήδη μνήμης με λάθος ονόματα. Αυτό που ο Task Manager περιγράφει σαν Memory Usage είναι όλο το Working Set. Αυτό που περιγράφει σαν Virtual Memory είναι τα private bytes. Αλλά, όπως είπαμε, τα private bytes μπορεί να βρίσκονται στη RAM, μπορεί να βρίσκονται και στο pagefile. Το πραγματικό μέγεθος της Virtual Memory που χρησιμοποιείται από μια εφαρμογή δεν φαίνεται πουθενά!

Αν θέλει κανείς να δει πραγματικά πόση μνήμη πιάνει η εφαρμογή του θα πρέπει να χρησιμοποιήσει είτε τους δείκτες του Performance Monitor ή ένα εργαλείο όπως το Process Explorer της Sysinternals, το οποίο δείχνει αναλυτικά τη χρήση της μνήμης για κάθε εφαρμογή. Και είναι και δωρεάν!

Τελικά? Τί περιέχουν τα 8MB shared memory που χρησιμοποιεί η εφαρμογή μου? Μα τα DLLs τόσο της εφαρμογής όσο και του framework!

Έλα Αλέκο? Πού περιμένεις να βρεις τα bugs? Στο testing? ...

Ψάχνοντας πληροφορίες για ένα κείμενο έπεσα σε μια καταπληκτική παράγραφο, στο Guidelines for Debugging του Visual Studio Team System. Δεν μπόρεσα να αντισταθώ και να σας τη μεταφέρω!

"Test will never be able to find all the bugs. It is not possible. Code is too complex. Even if test could find all the bugs, you would never have time to fix all of them. The right thing to do is to design your product so that bugs are not in the product from the start. Save yourself the trouble of fixing them later. You must take responsibility for the quality of your code. The test team just verifies the quality of your code. Do not depend on testers to clean up your mess."
Η υπογράμμιση δική μου.

Ή να το πούμε και αλλιώς: 3 testers δεν αντικαθιστούν 1 senior developer.

Architecture this, architecture that ...

Διάβασα πρόσφατα το άρθρο "What is a software architecture?" στο τελευταίο τεύχος του Rational Ezine. Αλήθεια, τί σημαίνει τελικά η λέξη architecture και τί σημαίνει architect? Φαίνεται λες και ο καθένας εννοεί κάτι διαφορετικό με τη λέξη architecture και architect, σε σημείο που να μην καταλαβαίνει ο ένας τί λέει ο άλλος σε μια συζήτηση.
    Τα πράγματα ήταν απλά πριν από μερικά χρόνια. Architecture ήταν χονδρικά η δομή και η συμπεριφορά ενός συστήματος. Το πρόθεμα software δεν έμπαινε γιατί πολλοί το θεωρούσαμε αυτονόητο. Αρχιτέκτονας ήταν αυτός ο οποίος σχεδίαζε τη βασική δομή της εφαρμογής, όριζε τα components, τις σχέσεις και τη συμπεριφορά τους. Ήταν το άτομο που ήξερε πως δουλεύει η εφαρμογή.
    Μετά όμως τα πράγματα άρχισαν να γίνονται πιο περίπλοκα. Αντί για desktop, άντε client-server εφαρμογές, αρχίσαμε να έχουμε n-tier συστήματα. Κάποια στιγμή αποκτήσαμε τόσους server και συστήματα που έπρεπε να ελέγχουμε που τρέχει τί και πως θα κάνουμε διαχείριση του φόρτου. Τελευταία, η κάθε επιχείρηση χρησιμοποιεί τόσα συστήματα που δεν την παίρνει απλά να αγοράζει ή να δημιουργεί ένα σύστημα για κάθε δραστηριότητα που θέλει να αυτοματοποιήσει. Σήμερα πλέον μια σωστή σχεδίαση δεν είναι αρκετή για να φτιάξει κανείς ένα επιτυχημένο σύστημα.
    Σαν συνέπεια αυτών των αλλαγών, οι αρμοδιότητες του architect έχουν διευρυνθεί σημαντικά. Ο architect πρέπει πλέον να ασχοληθεί και με τη σχεδίαση της υποδομής στην οποία θα τρέχει το σύστημα και με τα συστήματα με τα οποία θα συνεργαστεί τώρα ή στο μέλλον. Σε εταιρείες που χρησιμοποιούν πολλά διαφορετικά συστήματα, ο architect θα πρέπει να ασχοληθεί και με τη σχεδίαση των διαδικασιών και τα συστήματα που απαιτούνται για να δουλέψει σωστά η εταιρεία.

Η διεύρυνση όμως οδηγεί στην εξειδίκευση. Ο αρχικός ρόλος του architect έχει πλέον σπάσει σε διαφορετικούς ρόλους, με διαφορετικές απαιτήσεις:

• Ο Enterprise Architect ασχολείται με τη σχεδίαση των συστημάτων μιας εταιρείας ως σύνολο. Είναι αυτός που θα πρέπει να σχεδιάσει τις δραστηριότητες και τα συστήματα που θα χρησιμοποιηθούν, π.χ. από τους οργανισμούς του Υπουργείου Οικονομικών για την διάθεση και παρακολούθηση του Γ΄ΚΠΣ, από το επίπεδο του υπουργού μέχρι τους Δήμους και τις Κοινότητες. Στο επίπεδο αυτό αναφέρονται μεθοδολογίες όπως η Zachman ή η Motion της Microsoft.
• Ο Solution Architect είναι ένα υπερσύνολο αυτού που μέχρι πρόσφατα αποκαλούσαμε απλά architect. Όπως και παλιά, ο ρόλος του είναι η σχεδίαση μιας εφαρμογής ή συστήματος, λαμβάνοντας όμως υπόψη και την εγκατάσταση και ασφάλεια των εφαρμογών, την επίδραση του συστήματος στους τελικούς του χρήστες, την ευχρηστία του συνολικού συστήματος, τις ανάγκες συντήρησης και διαχείρισης. Εδώ αναφέρονται μεθοδολογίες όπως το MSF της Microsoft και το Rational Unified Process. 
• Ο Infrastructure ή System Architect είναι υπεύθυνος για τη σχεδίαση της υποδομής μιας εταιρείας προκειμένου να καλύψει τις λειτουργικές απαιτήσεις. Είναι αυτός που σχεδιάζει την υποδομή του Google ή του XBOX Live.
• O Software ή Application Architect είναι αυτό που παλιά λέγαμε απλά architect. Είναι ένας όρος που χρησιμοποιείται όλο και λιγότερο όμως, καθώς πλέον θεωρείται ότι οι αρμοδιότητες του architect δεν μπορεί να περιορίζεται μόνο στη δομή ενός συστήματος. Ο σωστός όρος για το ρόλο αυτό θα ήταν Software Engineer, αν δεν είχε χρησιμοποιηθεί ήδη καταχρηστικά για να περιγράψει οποιονδήποτε προγραμματιστή έχει περισσότερα από 2 χρόνια εμπειρία!

Αντίθετα, η έννοια του Software ή Application Architecture χρησιμοποιείται όπως ακριβώς και παλιά, για να προσδιορίσει τη δομή και τη συμπεριφορά ενός συστήματος.

Για όποιον ενδιαφέρεται, θα βρείτε μια πολύ καλύτερη περιγραφή των διαφόρων κατηγοριών αρχιτεκτόνων από τον David Platt στο "Architecture Type Definitions". Παρότι ο τίτλος αναφέρεται σε αρχιτεκτονικές, στην πραγματικότητα αναλύει τις κατηγορίες των αρχιτεκτόνων.

Πληροφορίες για τη μεθοδολογία Zachman θα βρείτε στο http://www.zifa.com
Πληροφορίες για την MSF θα βρείτε στο http://www.microsoft.com/technet/itsolutions/msf/default.mspx.

Τα πράγματα είναι κάπως περίεργα για τη Motion, καθώς έχει παρουσιαστεί ως τώρα στην Teched και σε κάποια podcast. Πριν αρχίσετε να ρωτάτε τους γνωστούς σας στην Microsoft για λεπτομέρειες, να έχετε υπόψη ότι είναι μια μεθοδολογία επιχειρηματικού επιπέδου: Ασχολείται με τους ανθρώπους, τις δραστηριότητες και τις διαδικασίες, όχι με components και application blocks.

700 hits σε ένα άδειο blog?

700 hits στο RSS feed του blog μου? Και δεν έχω γράψει ούτε ένα post? Το ξερω, το ξέρω, είμαι απαράδεκτος! Έχω καλή δικαιολογία όμως. Παντρεύτηκα τον Ιανουάριο!

Υπόσχομαι ότι από εδώ και πέρα θα γράφω και μάλιστα τακτικά. Έχω εξάλλου τρουλάχιστον 4-5 διαφορετικές ιστορίες και φιλοσοφικές αναζητήσεις που θα ήθελαν να μοιραστώ μαζί σας!