In a lot of ways, my employeer tends to be a first-mover when it comes to new versions of software. In that tradition, I decided to take Visual Studio 2010 and the .Net framework 4.0 for a spin.
Executive summary: Do… upgrade… now… at least if you do WPF in LOB applications.
I ended up converting all our projects to 2010 (albeit only one of them to .Net 4.0) – below I’ll outline the improvements that justified that in my case:
Performance – my impression on performance is that it has really paid off that MS decided to postpone launch pending performance problems. It runs a lot better on my system compared to VS2008. My system suffers from poor harddisk performance which lead to many IO-issues crashing 2008 – these issues are all gone (2 days of heavy refactoring without a single crash is a pretty good indicator). I use a lot of XAML – which was a pain in 2008 as simple changes in the editor could take up to a second to perform (a major issue when your typing speed is above 300 key-hits/minute. It is virtually painless now – the intellisense has been vastly improved and the editor feels snappy. RAM usage seems to have gone up – after a day of refactoring, I’m at about 700 mb for a solution with 15 assemblies loaded and ~17.000 lines of code and heavy use of XAML. I have nothing to compare to, as it was unlikely to have VS 2008 run long enough for it to go above 400 mb (roughly required a restart every 3-4 hours).
I upgraded R# within minutes – despite improvements, Visual Studio is still no where near in functionality when it comes to refactoring support. VS 2010 and R# combined makes for effortless typing – free-text search in type-search is a fantastic feature in complex solutions. R# seems a wee bit slower when it comes to context actions – but the jury is still out on that one. R# caused my only crash just after installing – it turns out that performing 8-9 refactorings via key-strokes almost instantaneously does not work (I forgot the actual combination and tried out the 10 I thought might be it…).
.Net 4.0 – lots of good stuff here – new controls (much missed DataGrid, DatePicker and Calendar) that actually look like the other controls (out goes the Frankensteins from WPF Toolkit) – and my absolute winner hands-down: Binding support in InputBindings – such an obvious feature, but finally it is here. Took away about 80% of my code-behinds ontop of ViewModels. And did I mention the new editor? Absolute goodness performance-wise.
Oh – and the icing on the cake: Fantastic multiple display support – I use three screens – and now I can have my solution/properties/errorlists on one screen, debugging on another and have my primary screen dedicated to code… it almost makes my eyes water. (Yes, I know that you could do virtually the same with floating windows in 2008, but for me it was inflexible, irritating and nitty-picky work to have it working – now it has full support for docking in all views).
A few things deduct though – the release of the Ribbon-tooling as a separate package… well, I’ll live. But why in the name of … did they not fix the SelectedDate-Binding bug of the DatePicker? I have yet to dig into the code of the controls, but it seems only the icing was fixed on the controls from the WPF Toolkit CTP.
So, in conclusion – VS 2010 seems all about improving that which was poor in VS 2008 making the platform a much more friction-free and mature workplace. In my book that pays off. I have yet to find a lot of new functionality (may be due to using R# on top), but I seem to be using more of the tooling now that it is less trouble to do so. The new-comers in .Net 4.0 with dynamics and such will have to wait for me to find a use for them – for me the new stuff is mainly corner-case functionality, but then, I’m not really missing a lot as it is.
Det her er egentlig mest en chance for mig selv for at danne et overblik over mine igangværende projekter (så jeg kan grine af det om 10 år…).
På arbejde er der ild i 3 forskellige projekter med varierende formål. Hovedprioriteten er vores brancheløsning, som kører i drift hos den første kunde, og som snart vil begynde at vende fokus mod nye moduler og ny funktionalitet. Der har været en del udfordringer i forhold til at performance-optimere det. Dels har jeg truffet et par uheldige valg i forhold til domænets opbygning, som har gjort query’ing tungt og dels har jeg været udfordret med en kraftig udskiftning i projektstaben.
Den næst-højeste prioritet er vores online booking. Den kører nu i drift hos tre kunder – det er en forholdsvis simpel løsning, men har indtil videre vist stort potentiale. Fokus her er på at få lavet de sidste kundetilpasninger og generelle små-funktionaliteter som vil gøre livet lidt lettere for vores kunders kunder. Samtidig er der et par integrationsmæssige udfordringer, som ikke er 100% løst endnu.
Sidst, men bestemt ikke mindst, har vi startet et pilot-projekt, som skal vise om vi kan samarbejde med en kon-kollega. Vi venter os meget af samarbejdet – foreløbigt har vi investeret en 30-40 timer på samarbejdet fra hver deltager (hvoraf omkring halvdelen er gået med koordination, møder og afklaring af funktionalitet). Så, det er i sin spæde start, men hvis alt klapper, vil det være en kæmpe fordel for begge firmaer – der er nu engang stor forskel på at gå fra at have en til at have tre at sparre med. Heldigvis minder vores firmaer meget om hinanden i forhold til hvordan vi tænker den fælles løsning – selvom firmaerne iøvrigt er vidt forskelligt drevet. Bare vidensdelingen og kompetence-bytning vil være af enorm betydning.
For første gang i udviklingsafdelingens historie har vi haft en måned med overskud… stort hurra (især fra min stakkels chef…) for det. Det vil nok være en enlig svale et stykke tid endnu – jeg siger snart goddag til en ny kollega, som skal hjælpe mig med at få styr på især test-delen af vores brancheløsning. Så der vil gå en periode med nedsat produktivitet indtil han har fået en chance for at sætte sig ind i løsningen.
Rent privat har jeg et projekt kørende med en tidligere arbejdsgiver, som dog er lagt på is indtil de finder ud af hvorvidt de skal ISO-certificeres. Det er for mig en lille hyggeopgave, der skal give dem et IT-system som understøtter deres nye LEAN-strategi. Omfanget er indtil videre ukendt, men vi har satset efter de lavest hængende frugter på tilbudsgivningen.
En spændende tid venter… Mange tiltag, der kan blive både en dreng og en pige.
My employer decided it was time to get our online booking solution up and running. So, I was put to work – having heard so much about Silverlight and RIA services, I decided to have a go at it. Having no experience with online programming besides simple html, I had to go with something that would smell a little like programming in WPF.
To give the judgement before letting the jury vote, I was not impressed. I certainly like the syntax (it’s pretty much like WPF), but RIA services didn’t really win me over. I tried various approaches – first with Entity Framework (re-creating the database-schema giving everything a primary auto-generated column), switching to NHibernate with huge difficulties – then back to Entity Framework with a few Include-attributes. Now, it was beginning to shape up – DomainDataSources and the RIA-services for filtering and serving up the data filtered and sorted/grouped… and then I lost control completely. Yes, XAML power is nice, but I found the DomainDataSource desperately wanting – especially with ComboBoxes (Async binding just blows up). Switching to AutoCompleteTextBoxes sort of remedied that, but the lack of control of when the loading happened just finally sent me packing. I tried reverting to skipping the DomainDataSource and controlling the RIA-service directly… that turned out poorly, having a cache, that I have to remember to clear and odd syntax gave me head-aches.
I don’t know, for me the RIA services is a nice project – it has promise, but it isn’t really production-ready for me. Being used to the fine-grained control, NHibernate gives me, the combination of EF and RIA just didn’t live up to my expectations. Also, having UI-logic (INotifyCollectionChanged et all) baked inside the DTO’s. Well, to make a long story short, it was the end of RIA services for me in this go. I then decided to go the more ‘hardcore’ WCF way – and switched Silverlight after reading the fine print… (how in the name of all that is sacred do you expect me to make LOB-applications without printing…) with an online XBAP (WPF).
And, now I’m back – three customers deployed today with their own individual graphical layout, one with a printed form. And best of all, I have all of the control at my fingertips again – I decided against a deployed WCF-service in virtual folders as the deadline was rapidly approaching and I had no idea how to do it. Instead, I went the albeit more old-fashioned way of Windows Services published via WCF. Fine grained control, SRP pretty much applied everywhere – full usage of a 2nd level cache thanks to NHibernate.
Of course, there are drawbacks (.Net 3.5sp1 is needed client-side, download size is huge compared to Silverlight and deployment is… considerable), but the most important criteria were met – our customers’ expectations and deadlines (one day ahead of schedule is a rarity in our line of business) were met in full (and in one case surpassed by a fair margin).
We have gone through some major refactorings lately due to performance problems. And while our performance has drastically improved – we are now at a point where further optimizations will prove futile. The reasons are many – the time we spend on performance tuning is now approaching a diminishing return, complexity in code is approaching problematic levels thus increasing cost of maintenance to name a few. I would now much rather throw hardware at it until it goes away.
Interesting bugs also rear their ugly head – it turns out that running our developement on the newest of the newest in terms of hardware and software versions is problematic, since our test customer is running on an erhm… let us say technically challenged platform. We are using every tool in the shed in terms of query-optimization in NHibernate – and it turns out there is a corner-case where certain combinations will work on SQL server 2005 but not SQL server 2000. I’m working on testing it on a small test project to prove that it is not us, that are idiots. For those interested – our bug manifested using HQL, a sorted query on a class that has joined subclasses with collections that we wanted to use subselects on in a paged resultset – and no lazy-load (yeah, not the simplest of scenarios…). NHibernate tries an optimization that uses the function Row_Number() which only works on on 2005 and later, thus throwing an exception. And yes, we use the MSSQL2000 dialect option in NHibernate.
So, before we do any further optimization on their solution, I want them to change to at least a newer version of their database software and get some decent hardware to go along with it. Next step will be cleaning up their workstations (4+ year-old-installations of XP perform… uhm… interestingly) and maybe upgrading them with DirectX 10. The problem is that they really do not want to spend much on their IT-infrastructure as they are planning on outsourcing it next summer, but right now their employees are suffering. Originally the plan was that they would have outsourced it already – we made it clear in the beginning that this new software would be hardware-hungry, but as the saying goes – “No battleplan is worth anything once the battle has started”, so we will adapt and overcome.
Så er mit første kursus vel overstået. Det var en fornøjelse at prøve at undervise igen. Alt taget i betragtning gik det også godt. Deltagerne var positivt stemte og havde bortset et par mindre ting omkring kursusmaterialet ikke det store at indvende.
Jeg var lidt nervøs før vi gik i gang – jeg havde kun mødt den ene af deltagerne og var i tvivl om niveauet, jeg skulle lægge for dagen. Det viste sig dog at jeg havde ramt tæt på bortset fra at vi nåede lidt længere end forventet. De får naturligvis en opdateret version af kursusmaterialet, når jeg har opdateret det med det ekstra.
Undervisningen blev en blanding af en hardcore-design session og så en gennemgående øvelse, hvor de fik lov at bygge en Outlook-klon. Ikke fordi det er nogen banebrydende øvelse – mange før mig har brugt netop Outlook som baggrund, men det gav mig en chance for at visualisere alle de ting i WPF, som hører hjemme i et crash-course. Jeg var samtidig lidt heldig med de deltagere jeg havde. De havde begge prøvet WinForms og Delphi, så det var rutinerede kræfter, som blot skulle omskoles til WPF.
De næste kurser bliver en udfordring dog – det her kursus ville jeg kunne holde stort set uden forberedelse. Næste gang bliver det med en eksempel-applikation, hvor abstraktionsniveauet kommer til at lægge langt højere og der skal arbejdes for at gøre det til en strømlinet oplevelse. Kursusmaterialet er godt og vel halvt færdigt – så det tegner til at alt nok skal lykkes.
Nu mangler jeg bare at få solgt kurserne til nogle flere…
Fra i dag har vi åbnet tilmeldingen til vores nye kursuskatalog ved min arbejdsgiver, TransSoft A/S. Det vil indebære en tilbagevenden til uddannelse for mig. Jeg har tidligere undervist og glæder mig til at komme i gang igen. Jeg vil dog stadig have mit primære fokus på udvikling – men jeg håber at undervisningen kan inspirere mig i min daglige udvikling.
Kurserne er bredt fordelt over emnerne WPF og agil programmering, hvor undertegnede primært skal varetage WPF-delen.
Vi holder kun kurser i emner, som vi har en aktuel og dyb indsigt i – og dermed kun de ting, som vi selv benytter til daglig. Vi håber at vi på den måde virkelig kan tilbyde kursisterne noget ‘andet’ end det de er vant til. Vi har selv haft problemer især på WPF-fronten med at finde kurser, der var på højt nok niveau og som samtidig blev afholdt i Nordjylland. Det er der hermed rådet bod på!
Everyone has seen them – every developer has fallen in at some point – the common pit-falls that are usability no-no’s. But how they are perceived varies. Developers with enough time under their belt will be at least partially blind to them – for some reason, active development will make you unable to judge usability unless you educate yourself.
This may sound a bit harsh – but it is actually true. When you know at least part of what is probably going on under the hood – you take a lot of things for granted. Of course that functionality is in the menu under Tools -> Settings – that’s the garbage can for any developer… but of course you should just right-click, hold control and drag it across the screen waiting two-thirds of a second for Windows to update the UI before moving out of the listbox.
And the things that annoy developers are unlikely to be the things that annoy Joe the Plumber and vice versa. Developers will complain – “But I have 47 controls – and if I don’t use up three rows in the tool-panel, the user will never see my brilliant functionality and I’ll spend hours explaining how to reach them”.
So, what to do? It’s actually quite simple, start looking at things that you don’t remember using – without looking, tell me how you activate the rear-view wind-shield viper? Most cannot. They will still be able to do it, when they sit in the car, but they will be unable to tell you. It is a combination of placement and icons incl. mapping. Cars must meet certain usability demands for drivers not to endanger themselves and everyone else on the road. All critical functions must be doable without taking your eyes of the road.
So, what does the car manufacturers do better than your average software developer? They spend a lot of time and energy on making sure buttons are where people expect them to be, make them of varying size and texture to allow the driver to find them without looking. And they place all the controls you need the most (steering wheel, gear stick, the horn and light-controls) at the most convenient positions. The less-used controls are not hidden away, but placed in secondary positions and less convenient to avoid taking the focus from the critical ones. (And of course, the car stereo designer still has not learned anything – I count 34 buttons on mine – 33 of them identical in size, colour and texture with tiny icons with made-up acronyms on them).
And they don’t start switching the brake-pedal with the accelerator, because it just seemed more aesthetically pleasing! Nor do they start making the car turn right when you turn the steering wheel counter-clockwise. (So, for goodness sake, stop placing the cancel-button to the left of the ok-button) In other words – they follow conventions even if it might conflict with other goals.
To sum up – to make better UI-designs – stop trying to invent the new and better wheel – and rely on already established conventions and use the hard-earned lessons other people have learned before you.
I recently started re-aligning my preferences when coding. Up until now, I’ve been focused on learning the technology and reaching a competent level of understanding why the technology works the way it does. Also, I wanted to write better code. I’m in no way among the most competent in these areas, but it is mostly a matter of using my new-found capabilities rather than gaining theoretical knowledge. So, I need new reading-material – and I started throwing myself at “The design of everyday things” and “Universal Principles of Design“.
I’ve always had a pet-peeve with badly designed software, but being unable to express what was actually wrong with it – I realized I had no vocabulary in usability. So, I started with these two books that are recognized as must-reads for designers generally. What I learned was not so much how to design beautifully nor how to design in the first place, but rather a vocabulary to express what I already knew and also, some research to back up my understanding of why design is important. These two books are not aimed at software designers in particular but rather the principles behind design in general. As such, many of the principles don’t really apply to software.
Most developers face a challenge when confronted with the word usability. They all know it exist, but most do not see the problems because having a technical insight makes you blind to the problems non-technical users have with their creations. Concerns are discarded just because the developer a) does not see the problem and b) cannot relate to the underlying cause.
The catch-phrase from my reading has been: “The user must see the conceptual model to understand the interface”. For us software developers, this means that if we are unable to convey the conceptual model of what we wish to accomplish in the GUI, the user will most likely fail. The conceptual model is basically “what happens under the hood” – in other words, it is everything the user cannot see. Humans are adaptable beings and jump to conclusions. This is why we have users saying “the computer freezes everytime I turn on the coffee-machine, so, since I started drinking tea, it has been running fine”. We (the IT-people) know this simply cannot be the under-lying cause, but the user does not know the technical bits – he saw to circumstances happen at the same time, and concluded that they must be intertwined.
So, what to do? Should we start educating users to be IT-minded – maybe throw in a MCP to make the users understand why stuff works the way it works? It would certainly make Microsoft happy… but no, it is not a viable solution. Instead, we need to focus on making better GUI. We need to make the conceptual model clearer and simpler. When the application fails, the error-message should not read: “Exception occured in major module hj_uuullk. Fatal failure reading harddrive kl_llij at position 0xE3F2E5″. It should read: “There was a problem with opening your document – you did nothing wrong. Technical staff has been informed about the problem and will fix it as soon as possible. If you want to follow progress: >link<. Please, do not attempt to open this particular document before technical staff gives the go-ahead. Other documents should work fine. If you need the document before, contact jim@farkvad.com.”. The user gains no insight from the first error message. Basically, he has no way of knowing if he did something wrong or it was a software mishap. All he knows that something went wrong, but he is left thinking… “Maybe my coffee cup was too close to the screen… hmm… could be that it was due to reading an e-mail at the same time…” The chances of him reaching the correct conclusion is slim-to-none.
The wife has kindly updated my wordpress installation and restored my old theme for your viewing pleasure.
I will return shortly with a series of posts around usability and general design concerns.
Nhibernate is extremely flexible and powerfull. Some details will have you tearing your hair out in frustration, though – at least untill you get that… ‘Ahaaah’ experience. Below, I’ll try to give you a few of the ones, that had me scratching my head:
The whole collection-issue that I mentioned in my last post can be frustrating if you missed the point with NHibernate using reference equality. In most situations you will not notice that one untill it is too late as it will be non-noticable in small datasets (if you are not paying attention to the SQL output, of course).
Another thing about equality – often, you will have entities publish an ID-field mapped to an Identity-column in the DB (for look-up purposes) and have it backed by a field. If you decide to use the ID for equality-purposes and have the property mapped with access: field be aware that any proxy from that persistent class will have different values for the field versus the property – the field will always be 0! So, always use the property in Equals(). Also, when considering equality in general, be sure not to use any lazy-loading entities as they will be loaded whenever equality has to be determined (WPF does a lot of that!). A rule of thumb is to use all properties for a value-type class (as per the DDD-terms) and only the ID for persistent aggregates (especially when they will be used as attached aggregates). The reason for this is that lazy-loaded entities do not have to be
evaluated (ie. loaded) to determine equality. I used to be a DBA in former employments and have spent a lot of time normalizing tables and I grew accustomed to mapping each fine-grained object to it’s own table – this is performance-killing! Consider the traditional simple Customer-class consisting of an accountnumber, a physical address, a billing address and billing information. If you map this to three-four tables (one for the customer, one or two for the addresses, one for the billing information) – NHibernate will unleash a LEFT OUTER JOIN hell of magnitudes (or a series of SELECT’s that will have your DB spinning out of control if you have yet to mark it to use sub-selects or outer joins)… Now consider when you start using the customer in other objects… The lesson here is that your typical one-to-one relationships with objects that will most likely not be null should be mapped as components and thus for the DB’s sake exist in the same table. Only consider a seperate table, if the associated class will often be null, or rarely used (lazy-load).
Inheritance and generics is another issue – just because NHibernate supports both, doesn’t mean you have to use it! It is most often not a perfect match and you will be twisting NHibernate into a knot to conform to your domain or vice versa. Also, remember that if you have an associated aggregate that is mapped with the base class – the resulting lazy-loaded proxy will always be the same type as the base class – never one of the derivatives. (See Ayende’s blog for further details as to why). Use it sparringly and be aware that mapping files do not support open generics – so, if your inheritance tree consists of a generic superclass – you cannot use it as the base class in the mapping unless it is a closed generics (and then it is a really advanced case – and you should really try for a simpler solution…). Generally speaking – using generics and inheritance in your mapping files will most often lead you into a world of hurt when the dependencies evolve and a key class in the inheritance chain will suddenly no longer conform to the dependencies. It is bad enough to have that happen to your domain – if you add data-migration head-aches to that mix… you’ll end up being wary of making needed changes to your domain.
All this said – if you stay clear of the pitfalls, NHibernate is a very nice fit for most agile TDD/BDD/DDD projects with databases as the early iterations will benefit from the easy DB-schema generation and the reduced DB-work. Later on, you’ll have to somehow solve the data-migration issues for projects in production – most customers will not take it lightly when you drop their databases for the new version to take effect… I have yet to find a silver-bullet there (there are products out there, but I have yet to need one badly enough to actually test them). My experience is that Active Record (which uses NHibernate under the covers) is really good for the early iterations – and then shift to full-blown NHibernate when you start running into the advanced stuff. DBA’s may seem like they get the short end of the stick and be out of a job, but it is actually a win-win situation – they get to do the fun performance-tuning part of their job in favour of the error-prone database generation part.
« Previous Page — « Forrige indlæg« Previous Page · Next Page »Næste indlæg » — Next Page »