« September 2005 | Main | November 2005 »
October 13, 2005
Potato, potatoe
Looks like Bob has gotten himself into a bit a of a sticky situation with regards to his blog. Not exactly the normal type of event I'm used to hearing about from Bob, but an interesting fight none the less for reasons of personal liberties.
The interesting bits to me are really the pieces behind the scenes. It seems the plaintiff in this situation has a notion of how computers work, or at least can get on the Internet to conduct a search. Unfortunately there seems to be no understanding of the technologies being employed, which only aggravates the situation. While no one outside of the Googleplex really understands exactly how Google's search algorithms work, there is generally a vague public idea and consensus on the basic behavior.
First, the
Second, crawlers. Googlebot currently visits my site about once a week. On pages that have a higher update frequency, Googlebot's arrival reflects this as well. It stands to reason that Google employs some type of LRU algorithm on pages, as it does not consistently request upon each visit every page from my site. Even if the index were updated, and changes were made by the defendant in this case, it's very possible that a Google search will still respond with the erroneous results. That is until the LRU reaches an update point and has Googlebot request every single page again. Bob seems to be pushing his luck a little bit with his responses. Anyone have some good advice or help to offer?
Posted by Dan at 02:08 AM
| Comments (0)
Due to some recent changes in the corporate environment, my group is being brought kicking and screaming into a world populated with multiple platforms. Many of these platforms contain foreign APIs and what not. In other words it will take a little effort to understand the changes before any meaningful work can be completed on the platforms. This time can take anywhere from days to weeks and is dependent upon numerous external factors. I've been pushing for the adoption of a cross-platform toolkit, more specifically the adoption of the Qt toolkit. Having hacked on it a bit for EROS, I've come to really enjoy Qt as an environment over many of the other cross-platform systems. To enable this push, both group and division wide, I've been forced to demonstrate a port of some established applications to the Qt system. Not a terribly challenging task until you realize a couple of truths about software development: 1) Code Maintenance is for wimps. Yep, you heard it here first. The larger the project codebase, the more important the project must be. The more important the project, the more likely you are to have a future at the company, so remember kids, build really large and complex applications to do a really simple feature. 1.5) Requirements come and go, but no one knows which ones are the right ones currently. The code base was originally written by someone unaware of what the entire project scope was. Or whose the original scope of the project has changed and evolved as new usage models emerged. Thus the codebase is littered with adapted code samples copy-written to others outside of the company, features not really needed, and unknown bugs. 2) No matter how non-evil your intentions may be, someone somewhere will always feel slighted by your initiative to cause change. In my case, someone has become very comfortable with using an obscure language for developing their tools. By definition, it's cross-platform, and thus is exempt from many of the issues Qt would solve. Unfortunately, it doesn't allow many of the lower level CPU controls or inline assembly needed for about 90% of our tools, hence why the tools are written in C and C++. 3) When something seems simple to you, there are always others who don't see it as such. Just because we'd only have to learn one API for many GUI, socket, and threading interfaces, it doesn't automatically turn into savings. Why? Because driver land APIs are still confused, and thus the entire possible savings are invalid. Why a driver needs a GUI though is beyond me... 4) Consensus does not mean action. Even though you might get agreement from all parties that this is the correct plan of action to take. It really doesn't mean anyone is willing to take the energy to put the plan into action.
Posted by Dan at 02:09 PM
| Comments (0)
Who was the idiot at Yahoo that allowed this abomination of an ad on their front page? Very very annoying. At least it only runs once.
Posted by Dan at 12:52 PM
| Comments (0)
Despite the current lack of involvement in the PHP project, I still follow a lot of the development discussion closely. Mostly by reading php-internals. Occasionally I'll make an opinion known to a poster directly, or possibly even to the list. Of recent interest is the debate over Derick's attempt to correct the functionality of PHP's date interface versus the already established user base interface. It's a tough issue with both sides making a valid point (or 5). The point isn't to opin a support of one or the other. Frankly, I don't believe using a technically incorrect implementation is the best idea, but if the user base doesn't care nor do I. What this does remind me of is another "make programmers happy" event... training. Between the programming worlds of academia and corporate exists a shift in thinking. The most recent language specific knowledge gained in academia seems to no longer apply as legacy projects are handed down, and stale developers are being tasked to continue their current track. While a project may currently be maintained by a very good developer, this developer may not be current in the standards of said language. The most common one I've found has been in the realm of C++, with a large number of people claiming C++ proficency but continuing to use pre-ANSI C++ methodologies. This can be further exacerbated by the fact that they refuse to update development environments (if it ain't broke why fix it?). Are there currently any training classes in "how it was before..." where before can be any time frame of significance for the technology?
Posted by Dan at 04:15 PM
| Comments (0)
Looks like in my great update to the MT server software I forgot to add my external reading. That's now fixed if you care to see what I'm reading lately...
Posted by Dan at 05:55 PM
| Comments (0)
Continuing the trend of how to make developers happy.... management. Management has the awful challenge of balancing out business needs with those of the staff, and often those needs are at polar opposites. While working at AGI I experienced one of those rare environments where both needs were inline. It was a glorious couple of years. Part of the problem is managers put into positions they don't understand. In smaller companies this is less of an issue, as the manager can typically be a former member of the group or have been there when the group started. In larger companies this issue is more pervasive. Some companies, like Microsoft, have tried to solve this by creating the PM, usually an employee with a strong background and a lot of interest in the subject. This works to a point as the projects stay small. Once again as projects get larger and more visible, the interest builds, people with different interests, backgrounds, and agendas move in to complete their tasks and suddenly you're back to the setup not working. None of this is new though. As a society we've invented entire schools of research towards this task, and pump out enormous amounts of graduates who are "qualified" to handle such problems. Between HR departments, and effective management books and training, there is an entire industry dedicated to help "solving" this problem. I sleep better at night knowing that "How to Be an Effective Manager" has helped saved groups. Really, I do. The largest problem software managers have is visibility. I'm sure this applies to a few other realms of engineering as well, but software is the one I'm most familiar with. On a properly executed project, a large amount of time is spent understanding the requirement, designing the right answer, and finally implementing it. Oh, and testing, lots of testing added with refining the design. This process has pretty much become standard for every project ever done (even outside of engineering). Where this changes is in the final producable. In the case of other departments, i.e. marketing or sales, there is a tangible to be measured against. Total sales may fluctuate, advertisements may be more readily seen, or the AC may actually work again in the building. Within the software world, especially in the confines of project maintenance, the final product still looks, (generally) behaves, and smells the same as it's predecessor. Under the assumption that testing resolved 80% of the most commonly annoying bugs, the last 20% are often bugs found in obscure methods that no one really uses, what did take all this time, effort, and money? The word processor function was working just fine before being re-factored, so what was the purpose? And why change it at all? End users are already familiar with the interface and expect to easily use the next version. At this point, the commentary begins to loopback into the first issue of keeping software development happy; projects. Why are new projects so important? The secret is in the corporate culture. Most large companies have an advancement process. Once or twice a year management asks you to collect "360 feedback", the process of having your peers (as defined by you) rank your performance. After that you write up your "brag sheet" which your manager takes into a closed door meeting and champions your case for performance. Out of this meeting you are now ranked corporate wide as either being 'needs improvement', 'average', or 'exceeding expectation'. Only the last will actually get a raise and be assured some type of job security. This type of corporate advancement has an adverse effect of forcing employees to constantly search out new avenues of work. The newer avenues of work will allow a greater internal corporate exposure, thus advancing a programmers ability to get job satisfaction through recognition. Further feeding into the source of the problem, a lack of developers willing to work on code maintenance due to minimal amounts of company exposure. This vicious cycle will leave projects dead by the wayside and programmers burnt out. [EDIT: grammatical correction]
Posted by Dan at 03:19 PM
| Comments (0)
October 09, 2005
Through the Valley of Darkness
October 07, 2005
What the...?
October 05, 2005
Melting the Polar Ice Caps
October 02, 2005
Restructuring
If The Phone Don't Ring, You'll Know It's Me