Feeds:
Posts
Comments

Archive for May, 2009

OK, I need to stop being negative on my blog, but this rant has to be posted publicly.

Twitter is a very useful service, and there’s a lot of new services popping up around it. Most of these new services actually rely on Twitter Search, though, and that’s where I’m in trouble. See, I’m invisible to Twitter Search. I’ve been using Twitter for nearly a year, but none of my Tweets appear. Makes it impossible to use hashtags, participate in Twibes and other things.

I first noticed the issue a few months back when I tried to start using a #wpfonyx hashtag when tweeting about my Onyx project. The hashtag wasn’t working properly, and it took me a while doing some research to figure out the problem was that I simply was invisible to Twitter Search.

On March 30, I opened a support request (Request 118748) explaining the issue. On April 1, @crystal closed the ticket with the following remarks.

Hello,

In order to appear in search, you must post updates first. If you haven’t posted updates yet, you may not be indexed in search. After tweets are posted to your Twitter account, they should be searchable, and so should you. If you haven’t posted updates yet, post some, and then wait. You should be indexed in search within 24 hours.

If you have already posted plenty of updates, and you’re still not appearing…

We did experience some delays with new accounts being added, but this is now fixed. If you’re still having problems, please check out this thread and add yourself to the comments with the info requested:

http://help.twitter.com/forums/31935/entries/29912

and we’ll help you out. If your problem is unresolved and has to do with something other than not appearing in user search or search.twitter.com, please reply to this email to let us know.

Cheers,
Crystal

Please note, this was a full closure of the ticket, which meant it was dead. Nothing I could do with this ticket after that. Also note that it was closed without a resolution. The link given doesn’t lead you to a posting which can be used to resolve the issue myself, but rather just takes you to a posting saying “yeah, we’re broke, nothing you can do, but hey, maybe you’d like to put a comment on this page to let us know you’re broken?”

I thought this was horrid tech support. No company I’ve worked with would ever treat a tech support ticket in this fashion. What it comes down to is, they have a widespread problem, and don’t want to be burdened with having to track hundreds (thousands?) of tickets for the same issue. Their solution is this public forum posting. That’s a non-solution. From the customer’s end, there’s no longer any accountability. There’s no way for me to track the progress of the issue. So I put my comment on the page like they asked (which I did, more than once), and then what? They aren’t going to tell me when my problem is resolved. Theoretically I can get e-mailed with updates to this page, which I am doing, but that’s more than suboptimal. I now get spammed with nearly 30 updates a day, as more and more people add comments about how it’s broken, or still broken, for them. Worse, though, not only am I not able to track things, but Twitter Support isn’t either. They made some correction that evidently helped some folks out last month, but it didn’t correct the problem for everyone. There was no way for them to know that, however, unless people added new comments to this page. Now Twitter Support has the same problems with tracking that I do, but compounded because of the likely failure to track by the users.

On April 21, I got fed up with this and opened a new request, Request 196806.

Do me a favor, don’t close this one out without actually resolving the issue, like you did Request 118748. Telling users to go to some "known issues" page and post a comment there is NOT providing support. Neither end can track the resolution of the issue through such a mechanism. That said, I _DID_ post a reply there, which wasn’t acknowledged. I posted a follow up, which was also not acknowledged. The problem hasn’t been correct, and I have no indication that work is even being done on the issue. This is extremely bad form.

My problem is simply that I do not get indexed by Twitter Search. You can find @wekempf in Find People, but none of my tweets appear in search. I’ve been tweeting for quite some time, so this isn’t a PBKAC issue. Nor is it related to what you suspect is the problem for everyone else in the indicated "known issues" page, because my account was created several months (nearly a year) before you believe the issue to have occurred. Not showing in search is a big deal. Hashtags won’t work for me. Various services such as Twibes won’t work for me. All in all, Twitter barely works if you don’t get indexed for searches.

This request was promptly marked as resolved (don’t know the exact terminology that Twitter Support uses here, but this is the state that should have been used with the first ticket, as it allows me to reopen the issue if I don’t believe it is resolved). The history on the ticket doesn’t show me the full history (yet one more thing they should fix), it only shows me the comments that I added. So I can’t reveal exactly what they said, but there’s enough in my response when I reopened it to give you an idea.

As clearly stated in this ticket, the previous ticket, and the infernal "known issues" threads, I’ve posted updates. This isn’t a PBKAC.
"Profiles added in the last 8 weeks aren’t being indexed by search. We’re tracking this problem here:
http://help.twitter.com/forums/31935/entries/29912"

And, as clearly stated already, my account was created much longer ago than that.

"Support requests reporting this issue are being closed, as we’re aware of and working on the problem. Please check the thread above for updates."

Translation: go away, don’t bother us. Well, $%@$ you. Yes, that’s not very professional, and probably won’t get me anywhere, but you know what? I’m not getting anywhere any way!

This ticket SHOULD NOT BE CLOSED UNTIL THE PROBLEM IS RESOLVED. It’s the only appropriate way to run ANY support tracking DB. The "group hug" site above leaves no accountability. MUCH worse is the fact that my issue IS NOT LIKELY TO BE RELATED TO THE ISSUES YOU ARE WORKING ON IN THAT THREAD. My problem doesn’t fit the profile you’ve put forth there. So monitoring that isn’t likely to do me a hill of beans. You’ll find whatever THAT issue is and move on merrily, while I’LL STILL BE IGNORED BY SEARCH.

"When you’re using ‘Find People’ to look for folks by name or user name, you can only perform 50 searches per hour before you’re limited– this is for abuse control and spam prevention. If you hit a search limit using Find People, try checking out Twitter Search’s advanced search:
http://search.twitter.com/advanced"

Doesn’t apply to me.

"If you’re not listed in search and your profile is public, we may be investigating your account for a violation listed here:
http://help.twitter.com/forums/26257/entries/18311"

Doesn’t apply to me.

"If you’re sure that doesn’t pertain to you and you still can’t find yourself or your friends, add your comments here:
http://help.twitter.com/forums/31935/entries/29912"

Yeah, this is oh so professional.

Yeah, I know, I was a jerk here, and I’m showing my dirty laundry to the world. However, I think I was justified in being a jerk, since I was being jerked around by them. I understand Twitter is a free service for me, but that’s no excuse for acting so unprofessionally here. Heck, they couldn’t even be bothered to read the ticket, as the majority of their response had already been explicitly addressed.

So, in my humble opinion, Twitter Support needs a major overhaul. However, the problem isn’t just Twitter Support. Obviously Twitter Development has some major problems as well. They have a known issue that’s impacting a very large number of users. It’s a fairly serious issue, and not just a minor inconvenience. This should be high priority. In addition, as a developer myself, it seems to be a problem that shouldn’t be that hard to diagnose and correct, and if it is, that would just speak volumes about the codebase. Yet, here I, and many others, are… invisible.

This seems to be nearly as big of an issue as the stability problems Twitter suffered a while back.

Update:  On 5/13, Twitter shut down the forum page, claiming the problem was fixed. They also closed my support ticket. I was skeptical that the "fix" would apply to my own issue, and tweeted about it yesterday (along with several other tweets).  Today, I’m still invisible to search. So, my skepticism was well founded. They closed the ticket assuming the problems were the same, without testing, despite the fact I explicitly stated it was unlikely the issues were related. I’ve reopened the ticket, but I’m not holding my breath on this one.

Advertisements

Read Full Post »

In case you’ve missed the announcement, Microsoft has released a new toolkit as part of the WPF Futures which is meant to aid in the development of WPF applications that follow the M-V-VM (hence forth, I’ll call this View Model) pattern. Here’s my impressions of what was released.

First, I’ll look at the Word documents included. There’s two parts to this. Part 1 provides a general introduction to the pattern. The first section of this document discusses the “Model-View-X Paradigm”.  Eek. That rankles with me. Sorry, I’m nit-picking here, but this is meant as constructive criticism. Why Paradigm, instead of Pattern, which is the accepted word to use? In any case, this section seems to struggle a bit with describing what differentiates View Model from the other patterns, including a reference to Presentation Model with little explanation to why there’s a mention (such as, they’re the same pattern, perhaps?). I think this just lends further proof that we either should be able to communicate the differences, or we should stick with a single name for the pattern. The rest of this document tries to justify the pattern with a sample application, but I think the justification is poorly presented. The problem is that they work backwards, starting with a spaghetti implementation, refining it a bit and trying to explain why it’s better. I think it would work better to state why one would use the pattern up front, and then demonstrate the differences in an implementation. As it is, trying to figure out why requires reading the entire document. I’ll also note that the current structuring required putting the unit testing last, which many TDD and BDD practitioners will take issue with. When unit testing is such an important reason for why you’d use this pattern, I really think this is a mistake. I’ll also note that the section on commanding could use some work. There’s little explanation as to why RoutedCommands are problematic, and the one reason given isn’t even valid (the target of a RoutedCommand must be part of the UI element tree… which is disproved by the Onyx command binding services that easily create command bindings for RoutedCommands with the ViewModel as the target).

Part 2 provides a walkthrough of writing a contact book application following View Model pattern. The overview describes the roles of the three components: Model, View and ViewModel. I’ll take exception to the description of the ViewModel, which explicitly states the ViewModel should not be aware of the View. That’s not really a requirement of the pattern, and in fact, while you should avoid tight coupling as always, some knowledge of the View is often beneficial if not necessary. I don’t mind code/frameworks that are opinionated on this topic, but this isn’t a framework, and I’m not sure that Microsoft should be in the business of being opinionated on topics like this.

When you run the project template, it creates a project with four folders: Commands, Models, ViewModels and Views. I’m not sure how I feel about that. I will say that I’ve never used a folder structure like this.  My Models are nearly always in a separate project. I prefer my ViewModels to live right along side the Views, as it makes it easier to find and open these related components. Finally, my Commands are usually defined in the ViewModels and not in separate classes, much less folders.  This structure is typical in a web MVC architecture, but this isn’t MVC and I just don’t think I like this layout.

The template imperatively creates the View and the ViewModel and associates them in code. I don’t care for this at all, much preferring a declarative approach using the XAML markup. The association is also solely through the DataContext, which is fine, but I prefer to use a different DP (which usually sets the DataContext as well).  Within a View, the DataContext will change frequently (for instance, in ItemsControls), but I still want to be able to talk about the ViewModel associated with the child elements.

The template creates a DelegateCommand class with a good implementation. One sincerely hopes this is a stop gap solution, as DelegateCommand really should reside in a library (preferably the BCL) and not be generated by the template. In any event, the DelegateCommand is certainly a best practice, and appears to be the only such concept actually included here, which is strange. Where’s the ViewModel base? Where’s the helpers for validation, INotifyPropertyChanged, etc.  I realize this isn’t a framework, but there should still be more support from the templates.  How about a ViewModel item template that creates a class that implements INPC? One hopes that version 0.2 starts to address the low hanging fruit here.

The section on unit testing is going to be controversial. Not only did we not follow TDD/BDD as I pointed out earlier, but the walkthrough utilizes the “Create Unit Tests…” feature, which is a questionable practice even if you’re not going to follow “test first”. The “ClearContactBookCommandTest()” is long and complicated with a total of 6 asserts spread out through the entire test.  Definitely not unit testing best practice here.  What’s really heart breaking is that there’s even three sections of asserts with comments that read “// Validate something”.  Isn’t that a clear indication that they should be separate tests?

I hope future releases do a better job of promoting best practices here. The Toolkit is probably useful to some, though I won’t be using it, and I can’t point someone new to View Model at this as a learning point.

Read Full Post »

OK, it’s official. The WPF community loves the Model-View-ViewModel pattern. That’s wonderful! However, I have always had problems with the name. So much so, that I’ve frequently jokingly used the good Dr.’s MVPoo name instead.

So, what’s wrong with the name? As the good Doc explains, there’s a lot of variations on what’s basically the same pattern (forgive me for taking liberties here, as I do know that the variations have very important qualities that distinguish them as unique patterns in and of themselves, but once distilled down for the layman, they’re just different shades of red).  Adding a new variation on the pattern can be confusing enough that one should endeavor to ensure there’s no duplication, and let’s be honest, Presentation Model already exists. To be fair, as far as I can tell form searching the Internet on this topic, the first public exposure to Presentation Model was in May of 2004, while the first time Microsoft publicly used the M-V-VM name was in October of 2005.  It seems reasonable to me that this variation on M-V-C may have been independently “discovered” at the same time, so it’s more than easy to forgive the existence of two names historically. However, I still find it to be very unfortunate that we have two names for the same pattern.

In an ideal world, I would suggest we stick with a single name, and since Presentation Model was publicly first, we should go with Presentation Model. However, this isn’t an ideal world. The WPF community is too strongly entrenched with the M-V-VM name. The community is just not likely to give the name up, no matter what we do or say now. If it helps (and it helps me), you can think of M-V-VM as a variation of Presentation Model that’s specific to WPF and its data binding and commanding infrastructure. Unfortunately, for outsiders already familiar with Presentation Model, even this explanation is likely to cause confusion, but it’s better than no explanation at all.

OK, so I’m admitting the name isn’t ideal because of the existence of two names for the same pattern, but I’m also relenting to the pressures of the community who have already adopted the name. However, even then, I have some other problems with the name. Model-View-ViewModel is a mouth full.  It’s just too much to say and/or type. The acronym M-V-VM is less to type, but it still stinks. It’s a pain to type with the hyphens, and impossible to read without them. When spoken, it’s a tongue twister worthy of inclusion in the Fox in Socks book. I’ve heard from a few insiders that there’s a growing movement to correct this issue by renaming the pattern to just ViewModel (I assume they mean without the space, though I’d prefer View Model which is more in agreement with Presentation Model). This caused me to go over my angst about the name all over again.

If we’re going to change the name, you’ll have to get the community to agree with the change.  M-V-VM is so entrenched now, that I’m not sure it’s possible. However, if all of the more influential folks within the community were to adopt the change, it is possible that the community could be swayed. If we were to make that attempt, though, wouldn’t it be better to take the opportunity to reduce the name down to a single name? In other words, wouldn’t it be better to try and sway the community to switch to Presentation Model, which was publicly first and more widely known in the broader community? It seems so to me. However, one could argue that it’s more likely that we’d persuade the WPF community to change the name to View Model than to Presentation Model, because View Model is just a shorter way of saying the already entrenched Model-View-ViewModel name.

So, what do others think? Should we try and change the name within the WPF community? If so, what name should we try and change it to: Presentation Model, View Model, ViewModel, MVPoo?

Edit:  Some discussion about this blog entry has also gone on in the WPF Disciples list here.

Read Full Post »

Isn’t that diagram spiffy? OK, I’ll be the first to admit, there’s nothing that exciting about the image here. What I do find quite interesting is that it was dynamically created by a web service through the simple use of an <img> tag.

<img src="http://yuml.me/diagram/class/%5BBlog%5D<>-*%5BEntry%5D"&gt;

The text representation of the diagram can certainly be cryptic and complex, and you’d hardly want to use this for a very large UML diagram, but for blog posts where you want to highlight some design aspects, it can sure be a useful little tool.  Check out some other samples using the tool.

Read Full Post »