June 2007 - Posts
A week ago, I tried to purchase an X61 Tablet PC from Lenovo and had significant issues handling the sales staff, estimated ship dates and websites. This is my first experience with Lenovo post-takeover of IBM and I am very disappointed by the level of service I have received. It is clear that an IBM brand has been taken over by a Chinese company that understands little about client communication and support.
I have cancelled my order and bought the tablet from a reseller that had a few in stock, and who shipped the same day (http://www.shopblt.com which has been very courtious and responsive).
I have run into the following issues that made for a miserable experience with Lenovo. I hope that thetechnical support does not have the same issues, should I need to call them:
-
30 minute or more wait times on the phone to talk to a representitive
-
Sales people giving me very different answers (one claiming there are no production snags and it should ship in a week or two, another claiming 4 weeks
-
An estimated ship date of 4 weeks (4/20) after I purchased, without an explaination.
-
An "order status" stating "in process." When I called to cancel, I was told it was already sent to "configuration". Does this mean it was going to be shipped earlier rather than later? That may have kept me from cancelling my order.
-
Numerous problems with the website, including:
-
broken links (ex: "contact" on the bottom of the order status form)
-
Session timeouts that erase your shopping cart
-
Broken "chat with a sales representitive" on the sales page
-
TYPOS INCLUDING "SXGA" INSTEAD OF "SXGA+" that no one cares enough to resolve
-
Fake, on-going sales that keep changing names, pretending that the product is "on sale" to lure customers.
Better communication, reasonable hold times, and a bit more transparency would have gone a long way to improving my experience with Lenovo. I am hoping the product and support are up to the same standards as IBM held it to, but given my experience thusfar, I will not be reccomending direct Lenovo sales to any of my clients or friends. I was sad when IBM sold out to the Chinese, and now that I see what the Chinese have done to IBM customer service firsthand, I'm very disappointed in both IBM and Lenovo for the way this transition was handled.
For several months now, I've been collaborating with Josh Einstein about writing a post compiler for .NET. Our goal was quite simple: we wanted to supply the ability to generate code, such as:
The job of creating a post compiler to properly handle all of this is not simple, and is quite time consuming, however we figured the benefit to the community would make it well worth it.
At the time I did several searches looking for a solution but could not find any implementation that I found adequate.
Enter PostSharp, a solution conceived and written by a developer named Gael Fraiteur. Gael has hit the nail on the head, and has implemented an incredibly well documented and functional .net post compiler. In addition, he goes above and beyond my original expectations, adding attributes that allow for easily intercepting and adding or replacing different types of code. PostSharp not only makes the aforementioned operations easier, it adds a sense of aspect oriented programming to .NET (thats not as painful as ContextBoundObject).
PostSharp is simple, intuitive, and best of all, comes with a suite of very well commented code samples. Kudos to Gael for beating me to it!
Following up on my previous post about configuring ASP.NET for Japanese mobile phones, I thought I would write about another irritating aspect of developing for the Japanese mobile market: sending email to the fairly ubiquitous Japanese phone email system.
Oddly enough, the most advanced Japanese phones on the market are very picky about which content encoding and content transfer encoding they support. Unicode does not seem to be an option (go figure), and it seems to me that the email gateway may be where the software bottleneck is, more than the phone itself.
Anyway, I started by trying to use the System.Net.Mail.SmtpClient. In our tests, we found that the supported content-encoding was iso-2022-jp. Nothing else. Not unicode, not shift_js, just this somewhat awkward standard. Fine. So we set our MailMessage.BodyEncoding to this format, and found that the Japanese phones still would show jibberish, rather than real Japanese. Sure enough, SmtpClient supports sets the content-transfer-encoding to quoted-printable, something the Japanese phones (or gateways) do not support. After trying AlternateView and other classes in System.Net.Mail, we gave up trying to send using this class. It simply was not possible.
Unfortunately, we were forced to use System.Web.Mail.MailClient to send our emails. This is a crappy wrapper around CDO, and is deprecated in .NET 2.0. The advantage, however, is that MailClient will send a MailMessage.BodyEncoding as 7bit, the required content-transfer-encoding for the Japanese mobile market.
In brief:
-
Japanese phones require:
-
System.Net.Mail does not send in 7bit encoding, unless you use AlternateView. At this point, I could not get mail sent with AlternateView to display properly on the mobile device.
-
System.Web.Mail will send 7bit, but has the disadvantage of being depricated
Hope this helps someone! Best of luck!
In the Japanese market the mobile web is one of the most important web mediums for companies to target. Nearly every site has a mobile version that works with the major mobile carriers phone technologies. When developing for the Japanese market, it is important to develop a mobile site in addition to a full site, as some users only have phones and not a computer.
This article will cover how to properly configure ASP.NET Mobile 2.0 to work with the majority of Japanese mobile phones in the market.
Download KDDI .Browser File Here -- These browsercaps are imperfect (I haven't reviewed each and every setting), but will ensure that Japanese text renders properly in the browser).
ASP.NET Mobile provides the ability to change rendering of a web page based on the browser accessing the site. Because of the wide varieties of HTML supported in the Japanese mobile market (DoCoMo/imode perfers cHTML and XHTML whereas SoftBank prefers HDML). In addition, different browsers support different encodings (some use UTF-8, others use shift_js).
To support all of these, ASP.NET uses browser caps. Most of the browser caps you need to the Japanese market are included in .NET 2.0. Unfortunately, KDDI browsers seem to lack a browser caps file in ASP.NET. To resolve this issue, read on to find how to install a browser caps file into ASP.NET.
Installing a .browser file
-
-
Copy the browser file into the C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers folder.
-
Open a command prompt and change path to C:\Windows\Microsoft.NET\Framework\v2.0.50727.
-
Run aspnet_regbrowsers.exe /i to recompile the browser files into an assembly and add it to the GAC.
At this point your ASP.NET sites should be compatible with the majority of Japanese phones on the market.
Okay, here is something that is very frustrating to me. So many people do this incorrectly and it makes me feel insecure about giving my password to a website. The thing they don't do properly is password management.
In this day of web and hobbiests calling themselves developers, we've found ourselves with tons of accounts at every web property ever, each with a username and password. Users however seldom know how their password will be stored when they supply it. This leads to various simple but dangerous security holes.
Ways not to handle passwords
-
Never store passwords in plain text. Passwords should be stored with one-way hashes (such as an MD5) so that the hashes can be compared when a user enters a password to login. Storing passwords raw in a database not only makes you responsible for everyones lost passwords if someone hacks your system, but also is bad practice because DBA's have full access to password lists.
-
Never send a user their password for "forgot password" workflows. If you do the first, this should be obvious enough. Sending passwords via email is dangerous because anyone can sit down at users machine and open up a web browser history and Outlook; try "forgot password" on a few sites and get the users password to anything. Not very secure.
Proper ways to handle passwords
-
Store passwords with a one-way hash. Storing passwords with a one-way hash allows you to compare the hash against a hash you make when a user attempts to login, but secures the users password from the sight of both a potential hacker or a DBA.
-
Send links or new passwords to email accounts. When a user requests a forgotten password, send the user a single-use link to create a new password, or a temporary password they must change on next login. This will ensure the user can change their password, but the password cannot be compromised by someone with access to their email.
More Posts