It was a gray afternoon, the kind that makes people long for rain just to break up the dreary monotony of the sky. I was nursing a scotch, which was by this point in time far too diluted for my taste, as the ice had long melted. As I lit my fifth cigarette I heard a dull thump outside. Must be the paper. Late as usual.
You're working on a killer new app. Or a small niche website. Or really any kind of human-facing software. If you're like most developers, your primary focus is on functionality: before anything else, it has to work. How can anybody disagree with that? If it doesn't work, then what's the point?
I will freely admit that I have digital trust issues. In fact, I will go so far as to say that if you don't have these issues as well, then you are either not in the software engineering field, or you are being willfully ignorant. Allow me to explain my terminology and position.
In Authentication, part one I discussed the pros and cons of single sign-on, and if you've decided to use an SSO solution, that's great. However, if SSO doesn't fit your requirements, then you'll need to take care of storing your users' passwords. The first thing you should do when determining how to store passwords is apply the YAGNI principle. In other words, avoid overengineering.
Authentication is something that virtually every developer these days has dealt with at least once - and sometimes has purposely avoided increasing that particular counter. Security in general is hard to get right, and authentication is, arguably, at its heart. There is precious little out there today that has no need of authentication, so one would think that (1) by now there would be excellent, vetted, and widely-used authentication systems that can be plugged in to any app, and that (2) everyone uses such systems. Unfortunately, neither of those is actually true.
Sometimes I really miss the Linux shell on my Windows computers. I rely on too much Windows-specific stuff to actually switch to Linux for my everyday computing activities - not to mention Windows Phone development - but I do want more power from my commandline than cmd.exe provides by itself. I've customized my console experience pretty heavily on my Windows 8 laptop, and I'm pretty happy with it now. This post is both to help others do the same if they so wish, and to help me remember what I did for next time.
First, some background. I've got a new Samsung Series 7 NP700Z3A-S06US notebook (that name just rolls off the tongue, doesn't it?) and the first thing I always do when I get a new computer that I didn't build myself is wipe everything off the hard drive(s) and install the operating system from scratch. This applies even to the "Microsoft Signature" computers, which are supposed to be bloatware-free, but still contain too much unnecessary stuff for my taste. So, when I looked over the installed software on this machine, I decided that I might as well do my usual thing and wipe it.
I've been seeing code floating around that suggests that in order for you to get an assembly's version number in Windows Phone SDK 7.0/7.1 you have to call Assembly.ToString() or Assembly.FullName and then parse the output. Please don't do that. There is a better, more stable, and more supported way to get the information you seek:
new System.Reflection.AssemblyName(System.Reflection.Assembly.GetExecutingAssembly().FullName)
Most people by now are aware of the design changes from Visual Studio 2010 to VS11 Beta, and from Beta to RC. There were quite a few complaints about the Beta design, not the least of which included the lack of colors and the ALL CAPS tool window title bars and tabs. Now with the RC, the biggest complaint is that the ALL CAPS weren't removed completely, but were instead moved to the menus. So why is all of this going on?
Sometimes I like to play around with the registry to see what little tid-bits of info I can find in it. Here are some interesting entries I've found recently (and not so recently). It goes without saying that modifying registry entries is very dangerous, and you can brick your device doing it.
[HKEY_LOCAL_MACHINE\Software\Microsoft\Connectivity\CellularCPL]
"Show3GToggle"=dword:1
Cellular control panel (settings item) --> show/hide the 3G toggle option.
