For those of you who are fighting the battle of keeping up on SEO optimization tips, or maybe you are just getting started, here is a handy web site - http://www.seoworkers.com/ I have found that will scan your URL and give you tips on how to optimize. The feature I like is that they also include videos from Google experts telling you how to tweak that aspect of your page. Check it out and get ranked higher!
I ran across this post via the Code Project feed. If you want to stir up debate, define your personal criteria as to whether someone is a clown or a coder. I’ve been both. I think at some point in my career, I may have touched on just about ever clown the author defines. There was a time when I was working 16 hour days nearly 7 days a week for weeks straight building 4 software products simultaneously and single handedly. At that point, I think I turned into angry clown. I know the Senior Managers at corporate HQ turned into angry clowns when they saw my overtime amounts on my time card. (KA-CHING!)
Over my 20 year career I have been in some awful interviews and been on the other side of the table watching train wrecks happen. I have found that coders are the most difficult to interview. You can ferret out if a server administrator knows their stuff. But, you don’t truly know how a coder’s mind works until you get code produced. Peer reviews can be interesting when personalities and philosophies collide.
I’ve had to clean up ugly code left behind by others. Coding is an evolution of learning and applying lessons learned from previous projects. Being the perfectionist that I am, I know I would like to re-write code I wrote 11 years ago. But you know what? That code is still running, largely untouched, eleven years later and still delivering value to the user community. In the end that is what business is all about. Delivering that end value. It may not be heaven behind the scenes, like clowns in a clown car, but it is working. Besides, isn’t that what version 2.0 is for? To give us that chance to get everthing right this time. At least, that is our quest and our pitch to management. Sometimes we do get it right!
I had an amazing experience today. I realized just how neglected the system I inherited was while migrating users from an old out of warranty server to a new VM based server. Here are some indicators you might be out of date:
- Your server is out of warranty.
- Your server software is version 7 and hasn’t had a patch since 2009 while the currently supported version is 8.5.2.
- You don’t know how many actual users you really have.
- A Point of Contact listed in the software screen users see has been dead for several years (no joke – it’s true).
- One of your users is using a client that is version 5.x and the current version is 8.5.2.
- Most of your users have not changed their password in seven years or more.
- A user complained about something not working to “Somebody” two years ago and has been living with it ever since. You have it fixed in less than 30 minutes.
- There is no funding identified to support the system.
Those are just some tips I thought I would pass along.
If you are debating between the Windows 2008 R2 standard and web editions, you need to take a look at what you need to function. A while back I was able to get a free copy of Windows 2008 R2 Web Edition through the WebsiteSpark web site. It’s been sitting around waiting for me to get a machine to run it on. I recently picked up a used Dell Quad Core and threw the software on it. I then installed VMWare server so that I could run Ubuntu Linux on it. What I found is that the Web Edition does not include the network routing services role necessary for VMWare to operate, as well as a bunch of other roles. However Standard Edition does.
At first I was ticked, but I put my Information Assurance hat on and I saw the logic. The web server is one of the most exposed points of entry for threats. Thus it makes sense to make the web server as dumb as possible. It sucks however if you want to multi-task the server. So, I’m reformatting the machine right now with Ubuntu server and will run Win 2K8 Web in a VM.
The Department of Defense has been consolidating it’s IT resources for some years now. It has been a slow, painful contraction to consolidate computing resources. But, it is a necessary step. Gone are the wild west days of lots of organizations building their own local “county options” and throwing them on to the network. I used to work in an area where a government worker had to log into over 20 systems before ordering a single part. A study revealed that this worker lost 1.5 hours or productivity a day simply logging in and out. Now services are increasingly being consolidated to central data processing centers. Remember the old main frame days of spoke and wheel architectures?
The bad part is that when these services are consolidated, the contracted services become larger and larger. Thus it is next to impossible for a small business to break in or compete. There have been several articles and studies documenting that innovation comes from small business, not large ones. With a large one, you often get a lumbering bureaucracy that often limits innovation. The game then becomes to maintain the status quo and management becomes purely political. The large firms send out their hired lobbyists and well connected folks to drum up tens of millions of dollars in projects.
I have been learning Microsoft SQL Server Reporting Services 2008 R2 for my day job. While diving into the report builder samples I kept running into a mysterious ReportingService2010 class. After digging through Google search results for several hours, I found this link that describes how to run the WSDL tool to create the mystery web service proxy class. You’re welcome!
I’m waiting for PaintShop Photo Pro X3 to install after recently purchasing the drastically reduced price version. I’m too lazy to call support to have them unlock my X2 serial number after too many re-installs from switching computers. But, I still have a lot of files in .pspimage format. So, I am installing the newest bloatware version.
I have been a PaintShop Pro user it seems like forever. But, I’m ready to dump it. I liked it when it was a relatively light weight, relatively feature rich, graphics editor that I found great for web graphics. But, a few acquisitions later and the lofty vision of competing with Photoshop have brought the software to it’s knees. It takes forever to boot up and then has way more than I’ll ever use. Nobody wants it now, thus the bargain price. The only reason I’m installing it is to recover and convert some files I need.
I’m now using Paint.net as my lightweight editor. It doesn’t have everything I want in it yet. There are times when I still fall back to PaintShop, but I hate it when I do. Thus the lifecycle of feature creep. Another victim of magazine feature comparisons. They lost vision of who got them to where they were and thus alienated their base. If I were king, I would have kept the lightweight version and branched off the Photoshop competition for those who thought they needed it. Or, at least given users the opportunity to select how much bloat to install. Now they have neither customer base.
If you’re developing a software product, remember who got you where you are. It may just keep you relevant.
The final Space Shuttle flight began today heralding an end to an era in space flight. I remember the first launch. This combined with some other recent events remind me that everything gets replaced, eventually. This is true in nature as well as in our man-made creations. It’s also true in jobs. Back in the late ‘80s when I was emerging on the computer job scene, the Windows 3.0 programmers were in hot demand and I was lucky enough to talk my way into a start up that failed, as many do. I remember being presented hundreds of faxed pages of Windows 3.0 SDK beta documentation and told to figure it out on my Gateway 386 machine. But, from that point on I was a hot commodity changing jobs 4 times in one year getting pay raises at each change.
There are lots of resources available on the subject of supply chain management. Anyone who deals with production of widgets knows about supply chain. A great many successes are documented about shaving time off the supply chain to produce just-in-time inventory.
The Air Force maintains the Aerospace Maintenance and Regeneration Center (AMARC) in Tucson, Arizona. Retired aircraft are mothballed here. Often, the Air Force will recover parts from these aircraft to sustain the existing fleet. A few years ago, I attended a conference in Texas where Air Force participants were discussing how to improve their supply chain to keep a certain aircraft in the air longer. There were wrench turners of various descriptions along with supply chain and logistics specialists. Of course, the appropriate representation of senior management was there also. A discussion erupted involving a case where a critical aircraft had been grounded for a part at a critical time in the war effort. A part was ordered from the AMARC for urgent priority processing over the weekend. Crews worked to regenerate the required part, a truck as pre-positioned and ready to transport the part. But the part took much longer to ship than desired. A great discussion ensued about how to trim more time off the supply. Finally, as I recall, the team determined that the part didn’t ship until Monday. The ultimate reason why was that the requisite person that was needed to press “the button” within the mandatory information system(s) that coordinated the part movement didn’t work on the weekend.
I was recently asked to inherit sustainment of a legacy web application written in Visual Basic ASP.NET with an Oracle 11g back end. I have learned that I am the sixth administrator to sustain the system and my predecessor left about a month before I took over. The turnover that he received from his predecessor just a few months before has largely been lost. My predecessor stopped answering my e-mails. Thus, I was left scrambling trying to pick up the pieces.
Documentation on the database schema’s logic and organization has to be reverse engineered. The same state with the ASP.NET, VB code behind, and VB classes. There are SQL script files that I had to decipher in order to accomplish the latest data load for the client in short order. It took me about a week to patch Oracle with the latest update, figure out the production environment, and get the new data loaded.
I spent a couple of days after that banging my head on the desk trying to figure out the Visual Studio configuration and thinking that I was missing a DLL referenced in the project and went on a wild goose chase to find it. I finally gave up, rebuilt the VS project and found out the previous project file as all messed up and the DLL was vaporware. At least now I can compile a code set. I’m not even completely sure I have the correct code base as revision control was not in use and I have found at least six copies of the source code on the workstation, network share, and web server. The production code is obfuscated into compiled DLLs, so who knows. I’m going to have to rebuild the test and development environments and compare functionality to be reasonably confident.
The point I am trying to make is that companies/clients are largely clueless about the value of knowledge management in the software lifecycle. I am as guilty as anyone else about leaving minimal documentation about a project. If you’re intimately familiar with the project, what do you need documentation for? But, when that knowledge leaves, someone has to pick it up. Teams with high turnover rates usually have fragile code because they don’t understand all the pieces. Eventually the recommendation comes to re-write the application so that they can understand it, but then that team eventually rotates out and the cycle starts all over again.
Most managers don’t have a basis from which to judge good documentation and knowledge management. Most couldn’t tell you what good looks like because they’ve never seen it. But, they experience the cost in a number of ways; (1) lost productivity due to reverse engineering, (2) increased defect count resulting in more re-work, (3) decrease in system availability, and finally (4) losing a competitive edge to competitors who are out innovating them.
It’s a known fact that Programmers hate to write documentation. Die hard Software Engineers understand the value of documentation as part of the engineering process. The trap is managers who want to see tangible products at less cost and documentation is often the cost savings avenue. As long as production is running, the knowledge and documentation must be adequate right? But, have they ever stopped to measure the effectiveness of their knowledge management system? No. Because the production system is operating right now.
