Monday, February 1, 2010
As the swelling waxed then waned over the coming days, the slight pain and discomfort abated. But then it plateaued. After some days of wishful thinking, I finally went to see an orthopedic specialist. As he poked and prodded inquiring “does this hurt?”, my hopefulness rose each time I answered “no, not really!”. He eventually surmised, “I think you buggered your anterior cruciate ligament.” I thought to myself, “well, I don’t know what that is, but at least he didn’t say ACL.” Then as I teased out what the acronym would be for this alien-sounding name, my wife simultaneously shouted, “you tore your ACL!”. Stupid doctors and their fancy names.
It turns out, if your knee feels “funny” but you don’t have much pain, it’s a sign that you damaged the parts that don’t have nerves and blood attached to them: ligaments!
Of course, I was expecting to hear about how they were going to use carbon-nanotube scaffolding to span my torn ACL and infuse it with growth factors and stem cells to grow it all back in a week. Instead, they’re closer to leeches and maggots: using a “donor ligament” (think: someone who will never need theirs again). Nasty! And, who hasn’t seen the movie Body Parts??? If I get the ligament of a violent criminal, who knows what could happen to my knee? Uncontrollable shaking???
Wednesday, January 6, 2010
Ever since, though, some of my contacts are inaccessible! If I attempt to click on them in the phone book, I get an error box with "Contacts: system error (-1)" and it refuses to open. If I attempt to send a text message and manually enter the phone number of one of the corrupted contacts, upon sending I get "Message editor: system error (-1)". In fact, I can't even delete these corrupted contacts!
I've not yet found a good way to wipe out my contacts and pull them in fresh on a sync. Will I really have to reset my entire phone?
Wednesday, December 9, 2009
I get good GSM 2G coverage around home, but where I work (50 miles away) I've had coverage issues. At my desk in the building, I usually have one or zero bars. But sometimes I see a 3.5G or 3G icon where my usual GSM tower icon lives. But when I attempt or use voice or data in that 3G mode, it fails.
Through some Internet searching, I came across some information posted by "mdo77" at HowardForums:
1) Cincinnati Bell's 3G frequencies are 1700/2100 MHz, which is actually the same at T-Mobile's. AT&T uses the 850/1900 freqencies. All three companies (CBW, ATT, TMO) have the same 2G (EDGE) voice/data frequencies, however.
2) Any CBW phone that has any chance of 3G working has the 1700/2100 bands.
3) CBW's 3G footprint is local only. They have no 3G roaming agreements (at least any that are active). If you're outside of the Cincy/Dayton area, you're EDGE only.
4) Even if/when roaming in 3G is available for CBW customers, it will only be on the 1700/2100 (TMO) bands.
I suspect what's happening is that my phone is picking up the AT&T 3G signal and favoring it over any standard 2G GSM signal (there's actually an AT&T wireless building nearby). However, AT&T doesn't let me through because I’m not an AT&T subscriber. I suspect if I tried a SIM card from an AT&T Wireless friend, I would get AT&T 3G right my desk.
According to Nokia's specifications (http://www.nokiausa.com/find-products/phones/nokia-5800-Xpressmusic/specifications), the Nokia 5800 operates at 850/1900. It would seem, then, that the Nokia 5800 would achieve 3G on AT&T Wireless but not on Cincinnati Bell Wireless.
What troubles me, though, is that Cincinnati Bell Wireless sells the Nokia 5800. If the above is all true then why is Cincinnati Bell Wireless selling a 3G phone that won't work on their own 3G network? Is there any hope of the Nokia 5800 ever working at 3G speeds on your network?
Meanwhile, I've now taken my phone out of Dual Mode so that it still restrict itself to the GSM 2G network.
Monday, December 7, 2009
I've learned now that makecert.exe needs to be run with full administrative privileges (not just a Windows SDK command prompt) when running Vista or Windows 7 (I'm on the latter). It can make certificates all day long, but when it comes to saving them to the local certificate stores, it will fail. By running an administrative command prompt (in my case, I can the Windows SDK command prompt as Administrator), makecert.exe can successfully write certificates to the local store, e.g.:
makecert.exe -sr LocalMachine -ss My -a sha1 -n CN=LocalDevServerCert -sky exchange -pe
Doing this, I now have my externally-accessible outer WCF service communicating to my internal WCF service. The inner-serviced is using wsHttpBinding, a custom UserNamePasswordValidator and the now-installed custom certificate:
<serviceCertificate findValue="LocalDevServerCert" storeLocation="LocalMachine" storeName="My" x509FindType="FindBySubjectName" />
Likewise, in the outer-service's endpoint configuration to the inner-service, I'm using related configuration:
<!-- Usually, this is 'localhost', but in cert mode, it needs to match the subject(?) of the certificate -->
<dns value="LocalDevServerCert" />
In this way, I can now explicitly set the ClientCredentials.UserName.UserName in the outer-service's WCF client and invoke the inner-service's operation and the identity flows through.
But wait, there's more!
I'm still stuck where Silverlight calls the outer-service. I'm limited to the customBinding where I specify a transport (e.g. httpTransport or httpsTransport) or basicHttpBinding (i.e. HTTP, HTTPS). Either way, if I attempt to use transport-level security, such as UserNameOverTransport on customBinding or TransportWithMessageCredential on basicHttpBinding, I'm left with errors indicating that WCF won't send credentials over a non-secure transport -- that is, HTTP. Again, HTTPS is not supported by Cassini, and I can't get Visual Studio to work with IIS.
Next I'm going to investigate using Certificates for message-level protection between the Silverlight client and the outer-service. In production, I probably will use transport-level security via SSL on IIS; however, for local development, I could accept certificate-based message-level protection.
Still, why can't Cassini just support SSL? Or, why can't WCF allow credentials to be sent over an unsecured transport when bound to localhost? Either solution would make developers' lives easier!
The most likely "good" solution I keep encountering in wild web entails sending the username and password credentials from the Silverlight client to the outer WCF service as ClientCredentials, validating them in a custom UserNamePasswordValidator and hooking up my own custom MembershipProvider. Then, passing just the username down to the inner WCF service on the outer service's ClientCredentials, trusting that username implicitly, and again hooking up my own custom MembershipProvider.
However, to use any form of credentials passing in WCF, you must either have transport-level security or message-level security. Out of the box, transport-level security means SSL while message-level security means certificates. Here the fun begins.
I'll gladly use transport-level SSL security. Its good enough for now and its relatively easy. Mind you, I don't necessarily need SSL between the outer-service and inner-service, but I can live with that. Unfortunately, Visual Studio's default web environment, Cassini (WebDev.WebServer.exe) does not support SSL. I suspect this limitation isn't just to torture developers trying to do legitimate things, but to prevent cheapskates from trying to run their public production web applications on it. .
Without SSL, WCF refuses to even attempt to propagate any credentials, giving quite descriptive error messages like "Could not find a base address that matches scheme https for the endpoint with binding BasicHttpBinding. Registered base address schemes are [http]" and "Give up all hope." It restricts this to protect us from ourselves. I would argue they could at least accept SSL from localhost. This would still thwart the cheapskates while exonerating most of the developers wrongly punished by this limitation.
So I can't accomplish what I want to accomplish in my current development workstation and configuration. Temporarily peeling myself off of that brick wall, I downloaded the WCF Samples and started investigating message-level security. After much tinkering, I encountered a missing test certificate, so I followed the happy, simple instructions to execute their provided batch file. I was greeted with a handful of errors, including some Access Denied. I tried again from a command prompt with greater privileges and got a different set of errors.
So I turned around and went back to the brick wall that was SSL, this time aiming to have Visual Studio use IIS instead of Cassini. I went to the Web project properties of my WCF project and selected "Use Local IIS Web Server". When I attempted to save, I was slapped with this ominous error:
To access local IIS Web Sites, you must install the following IIS components: IIS6 Metabase and IIS 6 Configuration Compatibility Windows Authentication. In addition, you must run Visual Studio in the context of an administrator account. For more information, press F1. With little expectation, I pressed F1. I was not disappointed -- only because I had such low expectations to begin with: nothing happened.
Now I suspect a part of this problem is me. I'm still new to WCF, having only worked with it for a few months. I've not been to any professional training courses on WCF, and only have one book about it and have only read a couple hundred blogs, articles and MSDN references.
But is there also a lack of support for simple developer environments?
Tuesday, December 1, 2009
The result of my own poor judgement, my Nokia 5800 XpressMusic was drowned in a hot tub. The phone itself was only under water momentarily, but the battery was submerged over night. The next morning, I had to brush away a teal-green corrosive coating that had grown on one of the battery's contacts, caused by a small current flowing across the terminals underwater, no doubt aided by the highly chemically treated hot tub water.
My first action was to take off the cover of the phone, remove the battery, SIM card and microSD card and set them on a window sill to dry. After hours of drying and no visible signs of wetness, I attempted to install the battery and turn it on, but nothing happened. Thinking the battery might have been fully discharged, I plugged it into the charger to charge for a half-hour or so to get some juice in it.
Afterwards, it turned half-way on one time. by half-way, I mean the screen lit up and displayed "Nokia", but the handshake and tones never arrived. I turned it off and back on, and it was worse: only the red light and the omni button lit up, steady and glowing. I even tried the battery from my son's Nokia 5800, but it yielded the same results.
Fearing the worst, I did some research online. I learned some things, like:
- Put a drowned cellphone in a bowl of uncooked rice to dry it thoroughly.
- Never plug in a cell phone that may till have water in it
Oops! I had killed my phone! My son was even upset, and it wasn't even his phone (this time!) He even offered to let me use his phone (who says teenagers can't be sweet?)
I reverted to my scotch-taped Nokia 6300 (great phone -- just not a smartphone). After several days of no GPS, no touch screen, no WiFi, etc. my son started hopping around me, bright eyed with and bursting at the seams with a secret. Just before he would've exploded, he spilled to me that he "fixed my phone." On his own, he had tried his battery in my dead phone, still sitting in pieces on the window sill. This time, though, it turned on! I presume that when I had tried his battery in my phone, it had not yet dried, giving a false-negative