I really like Valve Software. Not only do they make great games, but they have a reputation for treating people well and keeping things in perspective. Their website has always been simple and efficient, they are innovative and supportive of smaller developers, and they are helping to fix the broken game publication and distribution system with Steam. I found this quote the other day in response to some Valve-doomsayers, and wanted to share it:
“I drive away from the company that was built from the royalties we made on Steam, in my sports car paid for by the royalties we make on Steam, to the home that I pay for with the royalties we make on Steam. If that’s exploitation, I’ll take a little more.” - John Gibson, president of Tripwire Interactive, makers of Red Orchestra and Killing Floor, on whether Valve is exploiting small game developers via the Steam distribution platform. Source : http://www.1up.com/do/newsStory?cId=3176474I sent a facebook message this morning to a nice fellow that was complimenting my wife… 
I recently installed an app on my iPhone that integrated with my Google Voice account. It allowed me to place calls from my Google Voice number instead of my standard cell phone number, very convenient! In order to access my Google Voice account however, the application needed my Google password.
The moment I entered it, I regretted my decision. My Google account isn’t just some random service I use on the internet. It’s the key to a vast amount of personal and sensitive information about me - Gmail has all my contacts and communication history both personal and professional; Google Docs has my financial information; Google Checkout has direct access to my credit cards for making online purchases, Google Notebook has information on many of my current projects that would take months to catch up on if I lost access, iGoogle has my to-do and wish lists, Calendar remembers birthdays, holidays and appointments for me, my video game studio’s domain is linked to my Google account, as is the new domain I created for my day job, and of course Google Voice itself manages the phone number I’ve given to everyone I’m actually interested in hearing from. Giving up this password put me at risk not only of losing access to all of this information, but having someone use it against me. This is a risk I should never have taken. So within a couple of hours, I made up my mind to change my password. This is just a friendly warning - be aware of the access you’re giving out when you sign up for cross-site services. Whenever an organization or application asks you for your account information for another service, you’re opening up that account and everything that’s linked to it to the owners of the other site (and any black hats that might get into their systems). It’s easy to forget how the convenience and accessibility of today’s online world makes us vulnerable. I’m a pretty tech savvy guy, and I’m generally good at protecting my devices from external malice. But I’m stil susceptible to innocuous-looking “convenience” applications to link my various online identities together. It’s bad enough that most people use the same usernames and passwords for different sites. Consider your choices carefully. Related resources: Coding Horror - Please Give Us Your Email PasswordTraditional GUI-based tools are great for looking up information in a database or making a quick change to a single instance, but their utility often diminishes when you’re working on a prototype system.
For example, take the common scenario of a commercial application that requires a dedicated database. A prototype of the database is designed and created using the author’s favorite tool (SQL Server Management Studio, Oracle Designer, TOAD, etc.), and then exported into script form using that tool’s built-in utility. The resulting script is then used to generate copies of the database for the customers. The install process is rarely a smooth one, however. First of all, all the elements of the database mirror those of the development environment - users, passwords, and so forth. Those need to be changed, probably through some manual changes to the generated script. What about updates? Any changes to the database in new software versions create a dilemma: should the changes be deployed as a patch or as a whole database drop-in replacement? The previously described process of modeling the system in an editor and then exporting a script file isn’t granular enough to support most patching operations, but replacing an entire database creates its own problems - most notably the scale of the deployment procedure and the customer’s (usually reasonable) expectation that their data will persist through upgrades. Anyone who’s had to modify automatically generated code before probably sees the problem here - the job just got a lot more complex. Since no humans were involved in the creation of the script files, there’s no institutional knowledge about their structure, so every change must be carefully researched in order to ensure it does what it’s supposed to and doesn’t break anything else in the process. Then there’s the question of rollbacks. What if something goes wrong? Can the system be restored to its previous state? Not many database tools have an export feature for rollback scripts. The problem is, these tools simply weren’t designed to handle scenarios like this. On the other hand, engineering a custom solution can result in more robust systems in less overall time. Here’s a technique I’ve used several times to simplify database development and management. At a granular level, any change to database structure; creating or dropping objects, changing permissions, modifying data; can be encapsulated in a SQL (or PL/SQL, or Transact SQL, etc) script. Where database visualization software frequently gloms all these SQL statements together into large “install” scripts, I propose treating them discretely. The important distinction is that for each action, there is an associated “undo” action that returns the database to its prior state:Any install, upgrade, or rollback activity can be defined as a sequence of these types of actions. Scripting these operations as part of any release can go a long way toward streamline testing and deployment of your changes. (more…)Action: create table
Undo: drop tableAction: grant permission
Undo: revoke permissionAction: drop table
Undo: create table and restore all data
I’ve been seeing more and more people rely on “lines of code” to measure various things in relation to a software project - its size and scope, the amount of effort required to create it, defect density, and so on.
Unfortunately, the “lines of code” measurement is a poor method at best, like measuring a painting by the number of brush strokes. It tells you nothing about the complexity, quality, or composition of the piece itself. There are, unfortunately, few aspects of software that can be quantified in a way that suits today’s charts-and-graphs management methods, so this metric has been relied on to produce a wide variety of measurements in recent years. While it may have some utility in comparing codebases with similar designs and styles by the same author, it is more frequently used in less meaningful scenarios. The truth is, a million lines of code can be rewritten into less than 20,000, and vice versa. And when you take into account that most projects are developed by multiple programmers, using a variety of styles and approaches, you quickly come to the conclusion that even within a single project, a “lines of code” comparison is, at best, an arbitrary measurement criteria. Is there a better option?. Personally, I like the idea of “use cases”, especially when it comes to measuring defect density. Defects in a physical product are measured by situations in which someone tries to use the product and is unable to do so due to a defect. Why shouldn’t the same be true for software? Of course, figuring out all the possible ways someone could use a program is no walk in the park, but we could start by looking at some of the tools that already exist to trace logic paths in an application and identify each potential sequence of commands that could be executed.Google Apps, the suite of online office applications from the Mountain View giant, has been available in various forms for a number of years. Only recently, however, have they started marketing the product to businesses. As part of this marketing effort, Google representatives toured several major cities, inviting users of the software to visit and discuss its uses. I attended one of these events, and this is my review of the offerings.
The Google Apps suite consists of several applications, including Gmail (email service), Google Talk (chat and messaging), Google Calendar (scheduling system), Google Docs (spreadsheets, documents, presentations), and Google Sites (web portal with custom gadgets). Most of these applications offer similar features to those we’ve come to expect from desktop software of the same genre. They also interoperate quite well, are available at low or no direct cost, and support importing and exporting of various file types. The services are hosted on Google’s servers, and are primarily web-based, with some exceptions - POP and SMTP access to mail, specialized mobile device versions, a desktop chat client, and some management utilities. Although Google does not provide details of their hardware platform or internal security measures, they are widely considered to have one of the most reliable platforms in the technology services industry, with no public history of security failures. From a technology and usability standpoint, Google Apps is an excellent choice of platforms for community and collaboration software suites. The software is updated and improved frequently, the help system is thorough and accurate, and the technology is powerful and easy to use. There are important limitations to consider as well. None of the programs in the Google Apps suite are available for hosting elsewhere - all operations are performed on Google’s servers. That means access to your files and applications is subject to the whim of your internet connection. Also, any sensitive information is not only being stored on another company’s servers, but can potentially be accessed via unsecure protocols. Finally, Google doesn’t open its doors to outside certification or accreditation authorities. If your system has to go through DoD Information Assurance Certification and Accreditation Process (DIACAP) or some other information assurance process, Google Apps is probably not your answer. Overall, Google Apps is a solid offering with strong capabilities in today’s business world. Its platform independence, ease of use, low cost, and reliability make it a competitive product suite worthy of consideration by any entity making a platform decision.
I just figured out how to spell bureaucracy.
I realized it’s based on “bureau”, like “bureau of public affairs”. It’s always been impossible for me to spell based on the sound.
Beaurocracy? Thats how it sounds, like “beautiful”.
But now I know.
Bureaucracy is not beautiful.
I had a chance to see Avenue Q performed in DC this week, and it was great. A novel storytelling approach, a great set, some fantastic acting, and ingenious writing. I can’t say anything bad about it - I had a wonderful time.
I didn’t go to a lot of events or organized entertainment in my youth, so my idea of a good time has historically been relaxing at home, wandering around town / the wilderness, or maybe going out to dinner or a movie. Since moving to DC, I’ve been amazed at the variety of options on any given day - concerts, plays, museum special events, not to mention the everyday “happening” places - it just goes on and on.
I think I’ll me sampling a lot more of these in the future. There’s great stuff to be had here.
I’ve been swimming pretty regularly for almost a year now at the local rec center. They have a nice pool, but like most nice pools around here, it’s crowded. It’s not uncommon for half the pool to be blocked off for water aerobics, high school swim meets, or other classes.
Some times are busier than others. Morning is better than afternoon, and winter is better than summer. This morning, I wiped the snow off my car and drove to the pool for a quick dip before work. It wasn’t too crowded - the parking lot was quiet and almost empty.
This was cool not only because it meant I could get my own lane, but also because the family of deer grazing in the woods right next to the parking lot wasn’t frightened off by the regular hubbub of people, letting me get a quick snapshot before they wandered away:
<chatting with a friend today>
James: I’m writing a fairly simple xml library designed mainly to be used to read configuration data (but can be used for any simple xml processing). The main usage is, most likely, you load an xml document and then query it for elements by name, etc. However, for reading configuration data, usually you just want one or two elements and don’t care about the rest of the document. For that, it’d be much more efficient to just seek into the stream itself for element tags with a particular name. I’m trying to decide what would be the best way to design the class so that you can use it for either loading method.
me: Well, first off, I’m tempted to ask why the hell you’re designing something that’s probably been written 100 times already. But, ignoring that: XML has its own built-in structure. You can’t identify things by element, you have to identify them by path or else they are meaningless. There’s a huge difference between root.person.dad.weight and root.person.mom.weight. You can’t just search for the weight tag.
James: Sorry, by name I meant to imply the path: ‘fully-qualified-name’
me: Ok. Then once you’ve loaded the data into some kind of structure, wouldn’t it always be faster to locate by path index and not by text search?
James: That’s jumping the issue, though. I’m talking about before even loading the data into a structure. Search the stream for a particular element you want.
me: You’d probably have to go with a hybrid approach. To find the element in the stream, you’d have to parse the stream anyway, at least until you got to the element you wanted. Because they don’t just sit together. I guess you could skip anything that didn’t fit. If it were me, I guess I’d make a single class / function that could operate either way. Search/discard or full parse/load. The operation is basically the same, except that in one case, you skip around based on your parameters.
James: I was thinking about templating the class so then you can use the same functions.
me: (highly amused, thinking what a bunch of fucking nonsense this would look like to anyone who isn’t nose deep in this shit like we are)
James: Yep. Don’t you just love programming? ;)